-
Notifications
You must be signed in to change notification settings - Fork 79
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
Create a mutating webhook to mount secrets #857
Create a mutating webhook to mount secrets #857
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've left a couple of comments already. I have done a manual test and the webhook certainly appears to behave as expected.
There are a couple of additional areas I think we need to think about:
- It would be good to have a CLI flag to disable the webhook for users who don't want it turned on.
- There are test failures. I think I may have figured out the failures in the integration tests. I am still looking at the failures in the e2e tests. These are all multi-cluster, so I suspect that maybe the webhook isn't being installed on data planes or something, but I haven't explored that path yet.
I'll comment further tomorrow.
// mutatePods injects the secret mounting configuration into the pod | ||
func (p *podSecretsInjector) mutatePods(ctx context.Context, pod *corev1.Pod, logger logr.Logger) error { | ||
if pod.Annotations == nil { | ||
logger.Info("no annotations exist") |
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.
If we're going to log here (and I think this logging might be a bit too chatty), can we include the pod name and namespace so that any unexpected behaviour can be traced?
// get secret name from injection annotation | ||
secretName := secret.SecretName | ||
mountPath := secret.Path | ||
logger.Info("creating volume and volume mount for secret", |
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.
Again, it would be good to include the pod name here.
@sseidman, nice work tracking down the e2e failures! I've completed my review now. This broadly looks really good, there are only one or two naming, unit testing and refactoring related things I'm going to suggest. (NB: take note of my comments on why the envtests are failing in case that helps, I think it is an easy fix.) |
Codecov Report
@@ Coverage Diff @@
## main #857 +/- ##
==========================================
+ Coverage 56.41% 57.08% +0.66%
==========================================
Files 96 96
Lines 9538 9335 -203
==========================================
- Hits 5381 5329 -52
+ Misses 3672 3545 -127
+ Partials 485 461 -24
|
SonarCloud Quality Gate failed. 0 Bugs No Coverage information |
@sseidman, apologies, I totally missed that you'd been pushing some commits over here. I'll follow up with a review tomorrow. |
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.
Looks perfect, thanks for addressing all my comments from the previous iterations!
What this PR does:
Creates a webhook that, as a default, creates volumes and volume mounts on created/updated pods for secrets that are specified via a specific annotation.
For example, a pod with the annotation k8ssandra.io/inject-secret=[{"secretName": "cassandraSuperUser", "path": "/etc/credentials/cassandra"}] will create a volume for the cassandraSuperuser secret and mount the secret to the path /etc/credentials/cassandra on each container for the pod. This will mount secrets in the default Kubernetes style, which will create a single file for each key/value pair in the Secret (e.g. there will be username file and password file for credential sets).
Which issue(s) this PR fixes:
Fixes #605
Checklist