-
Notifications
You must be signed in to change notification settings - Fork 173
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
Add annotations to configure Agent Cache #132
Conversation
- TLS is always disabled because there is no way to mount arbitrary volumes to the agent sidecar container
agent-inject/agent/annotations.go
Outdated
AnnotationAgentCacheUseAutoAuthToken = "vault.hashicorp.com/agent-cache-use-auth-auth-token" | ||
|
||
// AnnotationAgentCacheListenerAddress configures the address the agent cache should listen on | ||
AnnotationAgentCacheListenerAddress = "vault.hashicorp.com/agent-cache-listener-address" |
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.
Maybe this shouldn't be configurable but always be 127.0.0.1
. This really shouldn't be listening to anything other than localhost. Especially since the use-auth-auth-token
parameter is configurable, unauthenticated clients could retrieve secrets from Vault if misconfigured.
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 was thinking of allowing the user to change the port. Should I change this into a port configuration then?
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.
What is your thoughts with enabling the listener? If other containers in the pod want to use the vault agent as a proxy?
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 am not sure what you mean by this question. Do you mean what are my thoughts on allowing the listener to listen to IP addresses other than 127.0.0.1
? I think you're right that it is a bad idea.
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.
Just trying to understand the feature more in general.
We definitely don't want to bind to anything other than localhost, port configuration could be useful.
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 see. I think this is a very useful feature. Other than just proxying, the vault agent cache also takes care of renewing secrets. I have some applications that basically "outsource" the renewal duty to Vault agent. Otherwise, they would have to implement the logic themselves, which might not be trivial.
The agent cache also takes care of Vault's CA without having to require the user to somehow configure themselves to accept the Vault CA.
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.
Agreed with it being useful. I think turning this into a port configurable makes more sense.
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.
OK. I will make the change in a bit.
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.
Done. See f0dc686
@jasonodonnell Could we get this merged in if it's ok? There's been quite a few conflicts. |
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, thanks!
Any chance of a release with this feature? It just barely missed the 0.4.0 release |
Please do a 0.5.0 release with this! Would be really great if I could start using this and not have to do explicit agent configs to do have listeners. :) |
@tvoran and @jasonodonnell : Could you please make a new release with this? In any case, if you cannot wait, I've built and push a new image to The caveats are:
EDIT: Might also be great to include #167 for a "pure" agent cache usage scenario. |
We're planning a release soon @lawliet89, there's a few more PRs we're hoping to pull in for that release. Likely next week (August 17th-21st). |
@lawliet89 My apologies for the delay on this release. I wanted to circle back to let you know this release is planned for August 24th. Vault is currently being released and since the Vault container is an official Docker image, we need to wait for them to publish the new images, which can take a day or two. Once the official images are available on Dockerhub, we'll update Vault K8s internal references to the latest image and get this published. Thanks! |
It seems like those images got pushed 3 days ago. How come this release is blocked by the new image version BTW? These releases shouldn't rely on what vault version we're running. |
@reegnz, it doesn't really matter, but there are references internally for default injected image: vault-k8s/agent-inject/agent/agent.go Line 17 in 1ee5b2e
Whenever possible we try to update this to the latest image. 1.5.2 released late on Friday so Vault K8s releases today. |
* Add annotations to configure Agent Cache - TLS is always disabled because there is no way to mount arbitrary volumes to the agent sidecar container * Allow configuring listener port and not address
volumes to the agent sidecar container
Fixes #73