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

[Feature] Restrict Pod create and /exec permissions #30

Open
1 task done
chipzoller opened this issue May 21, 2024 · 1 comment
Open
1 task done

[Feature] Restrict Pod create and /exec permissions #30

chipzoller opened this issue May 21, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request security

Comments

@chipzoller
Copy link
Collaborator

Problem Statement

RBAC permissions are still unnecessarily wide today in that pods and pod/exec are granted too broadly. This isn't necessary as the only Pod which needs to be created and exec'd into is the datamover Pod.

Solution Description

Reduce RBAC permissions for Pod creation and /exec subresource to only the datamover Pod.

Alternatives

No response

Additional Context

No response

Troubleshooting

  • I have searched other issues in this repository and mine is not recorded.
@chipzoller chipzoller added the enhancement New feature or request label May 21, 2024
@chipzoller chipzoller self-assigned this May 21, 2024
@chipzoller
Copy link
Collaborator Author

Because of a combination of the need to support concurrent resizing operations across the cluster (both inter- and intra-namespace), and therefore the need to bring up Pods with dynamic names, coupled with the fact that resourceNames in RBAC rules[] does not support wildcards or regex, this may not be possible to do. Best we may be able to do here is pass a config option to tell DAS to only perform resizes serially and therefore be able to use a Pod with a static name thereby allowing more restrictive RBAC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request security
Projects
None yet
Development

No branches or pull requests

1 participant