search

spring-cloud / spring-cloud-vault

Configuration Integration with HashiCorp Vault
http://cloud.spring.io/spring-cloud-vault/
Apache License 2.0
274 stars 152 forks source link

Support AWS STS for the vault secrets backend for aws #572

Closed krisiye closed 3 years ago

krisiye commented 3 years ago

Is your feature request related to a problem? Please describe. Would like to get STS working with the vault secrets backend for aws under spring vault. Currently, it appears that spring vault only supports IAM User or (/aws/creds/:name) and not other credential types such as STS federation token or Assumed role (/aws/sts/:name). I do not see any configuration options documented for alternate credential types.

Describe the solution you'd like Ideally, we would have a configuration option such as credential_type that could be set to one among iam_user, assumed_role or federation_token that would then map these to either /aws/creds for iam_user or /aws/sts for the federation token or assumed role.

Describe alternatives you've considered NA

Additional context NA

mp911de commented 3 years ago

Feel free to submit a pull request. I'm not terribly familiar with AWS services so happy to collaborate on getting AWS STS into Spring Cloud Vault.

krisiye commented 3 years ago

@mp911de - Thanks. I might need some help on the Lease renewal. I'll come up with something for you to review.

krisiye commented 3 years ago

@mp911de - I was able to get AWS secret backend with STS working as part of the bootstrap (which sets up environment vars through the property source for aws access_key and secret_key along with a security_token. The Apps are consuming this as an environment variable and are happy as the app starts. However, upon lease rotation, I am not sure how these are supposed to be refreshed for the app. I noticed that upon a hard refresh (/actuator/refresh), the default system variables (cloud.aws.credentials.accessKey, cloud.aws.credentials.secretKey etc) are lost/removed from the property source.

Do we expect the application to add a listener for the SecretLeaseCreatedEvent, pick up new secrets and rebind any bean that may be using these properties?

I also see spring vault documentation here https://github.com/spring-projects/spring-vault/blob/master/src/main/asciidoc/reference/propertysource.adoc that suggests that the VaultPropertySource is updated for KV backends. Does the lease rotation also work with AWS secret backend?

Thoughts? Thanks!

mp911de commented 3 years ago

Right now, we don't support rotation because of the infrastructure that consumes the properties. In most cases, initial credentials get associated with some client (e.g. Mongo client, RestTemplate, …) and we have no chance to propagate refreshed credentials to the client which renders credential rotation useless.

I'm not sure about the AWS part whether there's a possibility to update credentials/whether the client components can look up credentials when needed from Environment.

For Consul, we added a dedicated refresh event (see https://github.com/spring-cloud/spring-cloud-vault/blob/477e8b9bb91531ab9ce14a1e8294f88a4c9b939d/spring-cloud-vault-config-consul/src/main/java/org/springframework/cloud/vault/config/consul/VaultConfigConsulAutoConfiguration.java#L39-L50) that rebinds the specific ConfigurationProperties instances.

Paging @maciejwalkowiak and @eddumelendez to chime in.

I noticed that upon a hard refresh (/actuator/refresh), the default system variables (cloud.aws.credentials.accessKey, cloud.aws.credentials.secretKey etc) are lost/removed from the property source.

That's expected behavior. However, these properties should come back eventually. If not, then this is a bug.

krisiye commented 3 years ago

@mp911de - Please review the PR attached when you have a chance. Like you suggested earlier, it's best for application teams to rebind/refresh any dependencies as needed. Also the issue with a hard refresh, maybe something to do with the permissions (403 forbidden) on my end when attempting a /v1/sys/revoke.

FYI - I wasn't really sure about adding any integration tests as it depends on key/role setup etc.

Tested on a pod against Kubernetes. Works as expected and is able to rotate the lease after the configured expiry threshold and updates the property source.

krisiye commented 3 years ago

@mp911de - Confirmed the issue I noticed above with revoke to be unrelated to the permissions. Seems like an out-of-order loading problem upon refresh. I have logged an issue for this one: https://github.com/spring-projects/spring-vault/issues/633