-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add features regarding getMetadata and signing #3
feat: add features regarding getMetadata and signing #3
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @Two-Hearts has provided some more detailed feedback, so I'm focusing more on higher-level project feedback. :-)
Overall, from a Vault integration perspective, I think this mostly looks good!
As far as testing goes, @ncabatoff has been working on a a new Docker-based external testing interface. github.com/hashicorp/vault/sdk
is meant to be imported by other projects and so would be a great fit for spinning up a Vault instance for testing. I think this example in PKI's test suite might give you an idea for using it. :-)
Let me know if you have any questions, excited for this!
} | ||
|
||
signature := resp.Data["signature"].(string) | ||
items := strings.Split(signature, ":") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be good to verify that there are three elements, that the first is vault
and the second begins with a v
and is a (version) number.
I'm not sure if there's a place we could save the version somewhere (in case we wish to verify against exactly that key version in the future), but if not, we can probably discard it for now :-)
internal/keyvault/keyvault.go
Outdated
|
||
func (vw *VaultClientWrapper) GetCertificateChain(ctx context.Context) ([]*x509.Certificate, error) { | ||
// read a certChain | ||
secret, err := vw.vaultClient.Secrets.KVv2Read(ctx, vw.keyID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the part I'd ideally like to replace with a pure-Transit solution. I think hopefully with a community member's help on the Vault side, this could be done purely via Transit (one secrets engine/mount point) and not via two (KVv2 for x509 cert storage and Transit otherwise).
But for now, this part looks good.
Is there a desire to target all versions of Vault, or could we perhaps institute a higher minimum version in the future (like 1.15, which isn't out and will hopefully be the version containing native x509 support in Transit)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cipherboy It would be great if Transit
could support uploading/downloading certificate chain in the future. For now, looks like we need to stick with the KVv2 option.
internal/keyvault/keyvault.go
Outdated
log.Fatal("Error loading vault address") | ||
} | ||
|
||
VAULTTOKEN = os.Getenv("VAULT_TOKEN") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned this over on the proposal:
But one of the issues with this approach is that the environment variables will need to be modified whenever the Token expires and needs to be re-fetched. While you can use the root token, it is a highly privileged token and ideally you'd like to scope this service down to just the permissions it needs to run (ideally, just reading the certificate and signing the bundle).
I suggested on the thread that using Vault Agent could work well here: rather than explicitly configuring a Vault Token (or equivalently, handling authentication to Vault using something like AppRole/cert auth/...), you talk to Agent which acts like a transparent proxy and injects authentication into your request for you.
Agent handles the authentication & lifecycle of the token, you just talk (ideally over localhost) to Vault Agent (without authentication) and it otherwise "behaves" like a Vault server in that it injects the token into your request before passing it to the Vault server and then back to you.
Its one more dependency for those running this service, but very attractive since it handles a bit of complexity for you.
(Concretely, what this would mean would be making VAULT_TOKEN
optional.)
Anyhow, give it a thought :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @cipherboy, yeah, I agree. The Vault Agent
is definitely something we need to have in a production environment.
@OliverShang Could you add DCO by using |
Signed-off-by: olivershang <[email protected]>
Signed-off-by: olivershang <[email protected]>
This reverts commit 871f370. Signed-off-by: olivershang <[email protected]>
Signed-off-by: olivershang <[email protected]>
Signed-off-by: olivershang <[email protected]>
Signed-off-by: olivershang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]> Signed-off-by: olivershang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]> Signed-off-by: olivershang <[email protected]>
0dca167
to
d30ebc0
Compare
@FeynmanZhou Sure, I have fixed this issue. |
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]>
Co-authored-by: Patrick Zheng <[email protected]> Signed-off-by: Bingqi Shang <[email protected]>
Signed-off-by: olivershang <[email protected]>
Signed-off-by: olivershang <[email protected]>
internal/keyvault/keyvault.go
Outdated
|
||
func (vw *VaultClientWrapper) SignWithTransit(ctx context.Context, encodedData string, signAlgorithm string) ([]byte, error) { | ||
// sign with transit SE | ||
resp, err := vw.vaultClient.Secrets.TransitSign(ctx, vw.keyID, schema.TransitSignRequest{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One additional commentary here that I think is worth discussing: this approach hides the mount path problem currently.
See: vault.WithMountPath("my/approle/path")
in the README: https://github.com/hashicorp/vault-client-go
Currently this requires kv
and transit
plugins to be mounted at the default paths. We probably want the user to be able to specify a custom path (including namespaces)... Maybe via environment variable or config file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that makes sense. I think using a config file is a good idea.
Signed-off-by: olivershang <[email protected]>
Signed-off-by: olivershang <[email protected]>
Signed-off-by: olivershang <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as a first version of the project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Vault side of things looks good from my PoV :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Features including getMetadata, describeKey and signing.