Users have no visual indication when PSACT values have been set on a cluster

[jameson-mcghee]

Setup

• Rancher version: v2.7-head (Commit ID: 6cca23f)
• Browser type & version: Brave: v1.48.171 - Chromium: v110.0.5481.177

Describe the bug When provisioning a cluster with the Default Pod Security Admission value set to either rancher-privileged or rancher-restricted, there is no obvious indication to the user that this PSACT value is set on the cluster.

To Reproduce

1. Spin up Rancher on v2.7-head
2. Provision a cluster with Kubernetes Version set to v1.25.6+rke2r1 and Default Pod Security Admission value set to rancher-restricted
3. Once the cluster comes up as Active, navigate to the Cluster Explorer page
   • Note that there is no banner or other indication that the Cluster has PSACT restrictions
4. Navigate to the Projects/Namespaces page for the cluster
   • Note that there is no banner or other indication that the Cluster has PSACT restrictions

Result When setting a non-default PSACT value on a cluster, there is no banner or other indication that the Cluster has PSACT restrictions

Expected Result A banner or other visual indication is provided to notify users on the cluster that it has PSACT restrictions enabled

Screenshots:

Example PSP Banner:

[mantis-toboggan-md]

The default namespace inside the Default project is not created by the UI; if there are annotations that should be present on it depending on cluster configuration, that would. be a backend issue, not something the UI should be trying to add. If there's a requirement around default psa configuration for newly created namespaces based off cluster configuration it'd be helpful to include that here; I don't see anything in the two dashboard issues linked above.

[Sahota1225]

@samjustus I think this issue is within your team

[nwmac]

The defaults set at the cluster level are not available at the k8s level.

We only show where user's have configured PSAs at the namespace level through annoations.

I don't think we should do anything here.

[cnotv]

That default Namespace has no PSS labels in it, so it's not PSA relevant and therefore we do not show the lock 🔒 icon.

[jameson-mcghee]

The defaults set at the cluster level are not available at the k8s level.

We only show where user's have configured PSAs at the namespace level through annoations.

I don't think we should do anything here.

@nwmac, I would argue that a PSA is a PSA, regardless of if it is specific to a singular namespace or to a series of namespaces (i.e. all namespaces in the Default Project). I would even be ok with a "Project-level" approach (e.g. putting a lock icon next to the Project instead of the individual namespaces), to indicate that all namespaces in that project are being effected by cluster-level PSA settings, but that is more of a design discussion.

At the moment, the only way for a user to know that a namespace is being effected by a cluster-level PSA configuration is to either attempt to create a resource on that namespace (and receive an error), or to go into the config for the cluster to check., and I am basically looking for a way to show this status to the user while also maintaining consistency with existing functionality.

[jameson-mcghee]

That default Namespace has no PSS labels in it, so it's not PSA relevant and therefore we do not show the lock 🔒 icon.

@cnotv, you will note that the 3rd part of my Expected Results states "All namespaces in the cluster's Default Project have the correct pod-security.kubernetes.io YAML labels associated with them". By this I am referring to the PSS labels.

However, your statement confuses me. Are you saying that the default Namespace is NOT effected by cluster-level PSA settings (because I can assure you it does), or are you agreeing that the PSS labels should be applied to the namespace?

[jameson-mcghee]

The default namespace inside the Default project is not created by the UI; if there are annotations that should be present on it depending on cluster configuration, that would. be a backend issue, not something the UI should be trying to add. If there's a requirement around default psa configuration for newly created namespaces based off cluster configuration it'd be helpful to include that here; I don't see anything in the two dashboard issues linked above.

@mantis-toboggan-md, assuming by annotations, you are referring to PSS labels, then unfortunately I have not found a rancher/rancher ticket that discusses the addition of annotations. I have noticed that the calico-system namespace on all clusters (regardless of Cluster-level PSA value) do have a PSS label of "Enforce privileged (latest)", so there is precedence for the inclusion of PSS labels on namespaces during cluster creation, but I have been unable to locate the ticket/PR where this functionality was implemented.

[cnotv]

Could you please post the partial YAML of the labels of that calico-system and the other Namespaces which you expect to have this icon?

In order to generate that, you need to have a label ~prefixed by pod-security.kubernetes.io/~ like one below, since that's what the documentation says.

"pod-security.kubernetes.io/enforce"
"pod-security.kubernetes.io/audit"
"pod-security.kubernetes.io/warn"
"pod-security.kubernetes.io/enforce-version"
"pod-security.kubernetes.io/audit-version"
"pod-security.kubernetes.io/warn-version"

[cnotv]

That default Namespace has no PSS labels in it, so it's not PSA relevant and therefore we do not show the lock 🔒 icon.

@cnotv, you will note that the 3rd part of my Expected Results states "All namespaces in the cluster's Default Project have the correct pod-security.kubernetes.io YAML labels associated with them". By this I am referring to the PSS labels.

However, your statement confuses me. Are you saying that the default Namespace is NOT effected by cluster-level PSA settings (because I can assure you it does), or are you agreeing that the PSS labels should be applied to the namespace?

Each Namespace must have one of these labels as defined above.

[cnotv]

For the records, I have heard also someone else complaining to have this issue with the icon in calico-system, but when I updated the Docker version of Rancher, I had nothing like that.

~Could you please tell me in which scenario I'm supposed to have it? When I create a new Rancher instance?~ Ok I needed to create a new cluster after updating Rancher 😅

[cnotv]

@jameson-mcghee As far as I can see, in the new clusters created with the new version of Rancher, they have labels inside and this is why you see them. Other namespaces have them not.

[jameson-mcghee]

@nwmac, @cnotv, and @mantis-toboggan-md, after a conversation with members on the backend team, I have updated the title and description of this ticket, and changed it to an enhancement. Also @Sahota1225, has moved this out of v2.7.2 release. Let me know if this makes a little more sense/you have more questions.

[cnotv]

Ok, now that makes more sense 😅

[cnotv]

Also if I may suggest a place to add information about the cluster, the most logical and unique place should be next to name and logo/icon in the header, rather than 3 pages and all different from cluster? Although, there's no iconography bound to a PSA and we are already using a lock. I'll rather pick something and use the same everywhere, including PSACT? Sorry for the design comment.

[mantis-toboggan-md]

We'll have to consider what information users have available in the cluster explorer. As Neil touched on already, the PSA configuration set during cluster provisioning is a different context than the pages called out in this issue, and not all users who can access the cluster explorer necessarily have access to provisioning resources

[cbron]

Looks like all this was cleared up, but PSAC's and namespace's restrictions are independent. You can restrict a namespace either way. Therefore a NS label is not a good metric of whether or not a NS has a PSS restriction on it.

[cnotv]

How would you identify a NS which is restricted if not by label?

[samjustus]

removing team/1 until its determined we need to do something

[cbron]

How would you identify a NS which is restricted if not by label?

You would need to look at the PSA config the cluster was setup with, and if the NS is in the exemption list or not.

[kwwii]

While I understand the problem we're trying to solve, I think we need to take a step back and understand how we want to inform the user about PSA-related information. This use-case was never taken into account or planned for - adding alerts here and there is not the right solution, long-term.

[cnotv]

@cbron In any case, when you create an issue it's mandatory that you provide the technical specification which you want us to rely to, as this has been several times a complication to find out what is the actual need.

Example case, on top of what you already have accurately and correctly written:

Given a cluster which has key foo with value bar or configuration <snippet-yaml>, we need to address what described.

Specifically for your case: Step 3 and 4 expect the presence of a banner while within a cluster with PSA enabled. Which part of the cluster highlight the adoption of such?

How would you identify a NS which is restricted if not by label?

You would need to look at the PSA config the cluster was setup with, and if the NS is in the exemption list or not.

Re-reading the issue description it seemed like we were talking about Namespaces, although this seems a cluster scope.

[cbron]

@cnotv I didn't create the issue, and I'm not providing specs for this issue. I don't have an opinion on if this should be added or not. Though I do think it's too early to add a warning at the project level, as we haven't added support for that piece yet. Me and Sam were pulled in here because it was suggested that we need to assign PSS labels to default namespaces when they are created. This is incorrect as the PSAC covers this. I'm just explaining how the upstream k8s PSS/PSAC system works so we don't implement a PSS warning that looks only at the NS labels.

[cnotv]

That icon is just to inform the presence of PSA labels within the Namespace, so the logic is still valid.

Regards the Cluster level information about presence of PSS, this is still required to be addressed from the cluster configuration specifications prior design, so I change stage of the workflow.