-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Revoke permission to GET secrets from virt-handler #3001
Revoke permission to GET secrets from virt-handler #3001
Conversation
e248342
to
36fe46b
Compare
/retest |
5bef12b
to
6499120
Compare
In order to avoid giving virt-handler permission to GET all secrets across all namespaces, virt-controller will now render an additional secret volume mount to virt-launcher's pod. This will allow the launcher to read the secret from the disk. Signed-off-by: Daniel Belenky <dbelenky@redhat.com>
6499120
to
acb94e9
Compare
/retest |
1 similar comment
/retest |
acb94e9
to
07b848d
Compare
/retest |
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 test focus left. Apart from that looks exactly right to me.
tests/vmi_lifecycle_test.go
Outdated
@@ -312,9 +312,27 @@ var _ = Describe("[rfe_id:273][crit:high][vendor:cnv-qe@redhat.com][level:compon | |||
) | |||
}) | |||
|
|||
Context("with user-data", func() { | |||
FContext("with user-data", func() { |
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.
Context
Instead of resolving the data directly from a secret, resolve the data from a secret volume mount. This is done to eventually take from virt-handler the capability to GET secrets across the cluster. Signed-off-by: Daniel Belenky <dbelenky@redhat.com>
virt-handler had to GET secrets across the cluster to inject cloud-init user data. Now, this process is done by reading the secret directly from the disk using a proper volume mount. since virt-handler still need access to secrets in the deployment namespace, this commit grants virt-handler the ability to get secrets in the deployment namespace. Signed-off-by: Daniel Belenky <dbelenky@redhat.com>
07b848d
to
54e4a7c
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rmohr The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
In order to avoid giving virt-handler permission to GET all secrets
across all namespaces, virt-controller will now renders an additional
secret volume mount to virt-launcher's pod. This allows virt-launcher
to read the secret directly from the disk instead of having virt-launcher
to GET it.
Signed-off-by: Daniel Belenky dbelenky@redhat.com
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #2967
Special notes for your reviewer:
You don't see any functional test changes in this PR because those already exists from the previous implementation :)
Unit tests were adjusted to the new implementation...
Release note: