Closed lindhe closed 2 weeks ago
I think this PR will not work as expected.
It only works if trident is being installed in the cluster rancher is installed to, but not any cluster managed by rancher. Basically because the projects.management.cattle.io
resource is only available in the rancher cluster itself, but not a cluster created by, or imported into rancher.
# in rancher cluster
> kubectl get projects.management.cattle.io
No resources found in default namespace.
# in an created cluster
> kubectl get projects.management.cattle.io
error: the server doesn't have a resource type "projects"
I get around this issue, you need to create the pod-security.kubernetes.io/enforce: privileged
label before installing the trident-operator. Because the label is already there, the operator will not change the label, and the TridentOrchestrator
instance should reconcile successfully, if it is installed in the trident
namespace created before.
apiVersion: v1
kind: Namespace
metadata:
name: trident
labels:
pod-security.kubernetes.io/enforce: privileged
Strange. I was pretty sure that I tested it before creating the PR. I'll try and verify.
This was allegedly fixed in v24.10.0:
- Kubernetes: Fixed Rancher admission webhook preventing Trident Helm installations (Issue https://github.com/NetApp/trident/issues/839).
I have no idea which PR that was, doesn't seem to be anything linked in my issue. But I guess I'll close this PR then.
Change description
In Rancher, it is not enough to have `patch` permissions for a namespace in order to set PSA labels. It is also required to have the `updatepsa` permission on the `projects` resource, as outlined [here](https://github.com/rancher/rancher/issues/41191). This rule allows the Trident operator to set the PSA label `pod-security.kubernetes.io/enforce: privileged` on its installation namespace in Rancher. ## Project trackingI have no insight to your internal Jira.
Do any added TODOs have an issue in the backlog?
No added TODOs.
Did you add unit tests? Why not?
No. I see no unit tests for your Helm chart today, and I cannot be the one to introduce it for you. I can only build on what you already have.
Does this code need functional testing?
I don't know, it depends on your testing practices and current pipelines. It would be great if you had a pipeline that tries to install the operator in Rancher to see that it works, but I understand if you cannot prioritize a specific Kubernetes management system like that.
Is a code review walkthrough needed? why or why not?
No, it should be fairly straight-forward to read the diff without a walk-through. But I'm happy to help if needed.
Should additional test coverage be executed in addition to pre-merge?
I don't think so.
Does this code need a note in the changelog?
It is not required, but might be nice with a note mentioning that this fixes bug #839
Does this code require documentation changes?
No.
Additional Information
Closes #839