-
Notifications
You must be signed in to change notification settings - Fork 83
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
fix(charts): Remove unnecessary sensitive permissions for DaemonSet agent and Pod init #3522
Conversation
- apiGroups: | ||
- spiderpool.spidernet.io | ||
resources: | ||
- spiderclaimparameters |
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.
Thanks for the work! @kaaass. Is it even better if we put resources with the same verbs into a list of the same resources? example:
- apiGroups:
- spiderpool.spidernet.io
resources:
- spiderclaimparameters
- spidercoordinators
- spiderendpoints
- spiderippools
- spidermultusconfigs
- spidersubnets
verbs:
- ...
- ...
- apiGroups:
- spiderpool.spidernet.io
resources:
- spidercoordinators/status
- spiderippools/status
- ...
- ...
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.
Sure! I've updated them.
- patch | ||
- update | ||
- watch | ||
- apiGroups: |
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.
Would it be possible to remove this rule (get/list/watch
verb of *
)? This rule include get/list
verb of secrets
at cluster-wide, which may cause some security risks. @cyclinder
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.
Also same question exists in Spiderpool controller.
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.
Yes, You can boldly delete them. CI will tell us if we cannot get/list/watch some resources.
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! Let me give it a try
After the fix, some issues occurred, it seems that there is insufficient permissions.
|
Thanks @ty-dc. Seems like the removal in my latest commit is too aggressive. I'll revert them. |
Hi @kaaass, codes look good now, Could you squash the comments? now we have 6 comments on the PR. it would be nice if we can squash to one comment. |
…gent and Pod init Signed-off-by: KAAAsS <[email protected]>
@cyclinder Sure! I've pushed them |
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.
Thanks for the work! @kaaass
actually, I expect upgrading CI to test this PR @ty-dc |
ok |
What type of PR is this?
What this PR does / why we need it:
This PR removes unnecessary RBAC permissions for the DaemonSet agent and Pod init to avoid potential security risks. Technically, this PR does:
ClusterRole
for each workloadThis PR minimizes the deletion of permissions to avoid affecting the normal function of the APP. However, there should still be some unnecessary RBAC permissions (such as for the Deployment controller).
Also, this PR DOES NOT include changing the kubebuilder annotation in:
pkg/k8s/apis/spiderpool.spidernet.io/v2beta1/rbac.go
Which issue(s) this PR fixes:
Fixes #3420
Fixes #3361
Special notes for your reviewer:
The removed permission from the permission rules are as follows:
DaemonSet agent
delete/deletecollection/patch/update
verb ofnodes/pods
update
verb ofdaemonsets/deployments/replicasets/statefulsets
update
verb ofcronjobs/jobs
get/list/watch
verb of*
get/list
verb ofsecrets
get/list/watch
permissions applied in other rules will not be affected.Pod init
delete/deletecollection/patch/update
verb ofnodes
update
verb ofdaemonsets/deployments/replicasets/statefulsets
update
verb ofcronjobs/jobs
I am more aggressive in deleting the permissions of DaemonSet agent, mainly because DaemonSet will be deployed to any worker node in the cluster, so attackers have more opportunities to obtain the ServiceAccount token of DaemonSet agent.