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

chore: Audit template validator RBAC rules. #622

Merged
merged 1 commit into from Jul 11, 2023

Conversation

jcanocan
Copy link
Contributor

What this PR does / why we need it:
This PR is a follow-up of #616. For this auditory, we have used the same methodology described in #616. However, due to the fact that these rules are implemented in code, we have not been able to try on Tier 2 test suite.

jira-ticket: https://issues.redhat.com/browse/CNV-30721

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Release note:

Audit template validator RBAC rules

Template validator has and reconciles their owns RBAC rules. It generates
the `template:view` ClusterRole for multiple task such as functional
testing. In order to be deployed and run functional test the `get` verb
is not required on resources `templates` and `virtualmachines`.

Signed-off-by: Javier Cano Cano <jcanocan@redhat.com>
@kubevirt-bot kubevirt-bot added 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. labels Jul 10, 2023
@sonarcloud
Copy link

sonarcloud bot commented Jul 10, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@jcanocan
Copy link
Contributor Author

/retest-required

Copy link
Member

@0xFelix 0xFelix left a comment

Choose a reason for hiding this comment

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

/approve

Thanks!

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jul 11, 2023
@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 0xFelix

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 Jul 11, 2023
@kubevirt-bot kubevirt-bot merged commit b74f026 into kubevirt:main Jul 11, 2023
11 checks passed
@akrejcir
Copy link
Collaborator

@jcanocan @0xFelix , I'd like to know your opinion about RBAC permissions.
I always thought about them as 2 groups:

  • Read permissions: get, list, watch
  • Write permissions: create, update, delete, patch

When I created rules for the operator, I always added a whole group. I find it strange that we give the operator permission to list and watch but not get.

What do you think?

@jcanocan
Copy link
Contributor Author

@jcanocan @0xFelix , I'd like to know your opinion about RBAC permissions. I always thought about them as 2 groups:

* Read permissions: `get`, `list`, `watch`

* Write permissions: `create`, `update`, `delete`, `patch`

When I created rules for the operator, I always added a whole group. I find it strange that we give the operator permission to list and watch but not get.

What do you think?

Yes, it may be a bit strange. However, I've followed an approach where if something is not required, drop it. My idea was to get a minimal list of verbs. Nevertheless, it does not mean that make sense. So, we can revert all get verbs if that makes more sense.

@akrejcir
Copy link
Collaborator

No need to revert the change. I just wanted to know your opinion.

@0xFelix
Copy link
Member

0xFelix commented Jul 11, 2023

I agree with @jcanocan, we should follow the need to know principle. Even if those verbs are pretty similar.

@akrejcir
Copy link
Collaborator

Ok, thanks.

@akrejcir
Copy link
Collaborator

@jcanocan The jira epic is targeted to 4.14, so this should be backported to release-v0.18.

@akrejcir
Copy link
Collaborator

/cherry-pick release-v0.18

@kubevirt-bot
Copy link
Contributor

@akrejcir: new pull request created: #659

In response to this:

/cherry-pick release-v0.18

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@jcanocan
Copy link
Contributor Author

@jcanocan The jira epic is targeted to 4.14, so this should be backported to release-v0.18.

Thanks for taking care of this on my behalf :)

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/S
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants