helm: additional cluster roles for secretproviderclasses

[anapsix]

What this PR does / why we need it:
At the moment, there are no ClusterRoles created for SecretProviderClasses resources with aggregation to view and admin default roles. This prevents ClusterRole/admin and ClusterRole/view from accessing SecretProviderClasses resources.

Which issue(s) this PR fixes:
Fixes #835

[k8s-ci-robot]

Welcome @anapsix!

It looks like this is your first PR to kubernetes-sigs/secrets-store-csi-driver 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/secrets-store-csi-driver has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @anapsix. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[aramase]

@anapsix Thank you for the PR.

Please update the yamls in the manifest_staging/ folder, where we host the staging charts and deployment yamls. All the yaml changes will then be promoted into the released charts folder (charts/) with the next release.

[aramase]

/retitle helm: additional cluster roles for secretproviderclasses

[anapsix]

@anapsix Thank you for the PR.

Please update the yamls in the manifest_staging/ folder, where we host the staging charts and deployment yamls. All the yaml changes will then be promoted into the released charts folder (charts/) with the next release.

I believe I did @aramase. Please clarify if I should remove changes to manifest templates in charts/secrets-store-csi-driver/templates/ in favor of manifest_staging/charts/secrets-store-csi-driver/templates/?

[aramase]

I believe I did @aramase. Please clarify if I should remove changes to manifest templates in charts/secrets-store-csi-driver/templates/ in favor of manifest_staging/charts/secrets-store-csi-driver/templates/?

that's right! the changes are only made in manifest_staging. So you would need to remove the changes from charts/secrets-store-csi-driver/templates/.

[anapsix]

Roger that, @aramase. Thanks for the clarification. Done.

[aramase]

/ok-to-test

[tam7t]

I think this is good but we'd probably also want to add something for the manifest_staging/deploy/ so that they could be added with just the kubectl apply -f deploy/* in the future. (we can do that as a separate PR)

/lgtm

[anapsix]

I think this is good but we'd probably also want to add something for the manifest_staging/deploy/ so that they could be added with just the kubectl apply -f deploy/* in the future. (we can do that as a separate PR)

/lgtm

@tam7t, added the new ClusterRoles to the manifest_staging/deploy. Please let me know if I did not do it the way you've expected.

[anapsix]

Also, should I add the manifests to test/bats/tests/e2e_provider/?
And the following to the Test rbac roles and role bindings exist test in test/bats/e2e-provider.bats?:

  run kubectl get clusterrole/secretproviderclasses-admin-role
  assert_success

  run kubectl get clusterrole/secretproviderclasses-viewer-role
  assert_success

[tam7t]

Thanks! And yeah adding a case for test/bats/tests/e2e_provider would be great as a sanity check that the roles apply successfully

[tam7t]

/lgtm

[aramase]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anapsix, aramase

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:

• OWNERS [aramase]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aramase]

/label tide/merge-method-squash

[anapsix]

Thanks! And yeah adding a case for test/bats/tests/e2e_provider would be great as a sanity check that the roles apply successfully

eh.. too late, @tam7t .. sorry I didn't make in time before the merge
Btw, wouldn't make more sense to symlink some of those e2e manifest to the ones in manifest_staging?