Skip to content
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

Merged
merged 3 commits into from
Feb 3, 2020

Conversation

danielBelenky
Copy link

@danielBelenky danielBelenky commented Jan 19, 2020

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:

Revoke permission to GET secrets from virt-launcher

@kubevirt-bot kubevirt-bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. size/M labels Jan 19, 2020
@danielBelenky danielBelenky marked this pull request as ready for review January 28, 2020 17:03
@kubevirt-bot kubevirt-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 28, 2020
@danielBelenky danielBelenky changed the title virt-controller to mount cloud-init secret Revoke permission to GET secrets from virt-launcher Jan 28, 2020
@danielBelenky
Copy link
Author

/retest

@danielBelenky danielBelenky force-pushed the cloud-init-secrets branch 4 times, most recently from 5bef12b to 6499120 Compare January 29, 2020 15:16
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>
@danielBelenky
Copy link
Author

/retest

1 similar comment
@danielBelenky
Copy link
Author

/retest

@danielBelenky danielBelenky added this to the v2 milestone Feb 2, 2020
@danielBelenky
Copy link
Author

/retest

Copy link
Member

@rmohr rmohr left a 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.

@@ -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() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Context

Daniel Belenky added 2 commits February 3, 2020 16:55
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>
@rmohr
Copy link
Member

rmohr commented Feb 3, 2020

/lgtm
/approve

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Feb 3, 2020
@kubevirt-bot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 3, 2020
@kubevirt-bot kubevirt-bot merged commit 9efa8d7 into kubevirt:master Feb 3, 2020
@rmohr rmohr changed the title Revoke permission to GET secrets from virt-launcher Revoke permission to GET secrets from virt-handler Dec 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL
Projects
None yet
Development

Successfully merging this pull request may close these issues.

virt-handler daemonset can GET Secrets in all namespaces making it cluster root
3 participants