Add support for Pod Security Admission
See:
https://kubernetes.io/docs/concepts/security/pod-security-admission/
UX TBD
PSPs are going away in 1.25. PSAs are the new thing. As I understand it they are a lot simpler than PSPSs. If you look at that document, for namespaces, you can add a label that configures the mode for the pods in a given namespace, so I imagine we'll want to add that to the detail view for a namespace and also the edit view. You can also declare exemptions for pods, so that will require a change to the pods detail/edit screens. I don't know if there is a log from the admission controller that we could show to help users understand what pods were blocked by the configuration. Rancher does not officially support k8s 1.25, so one task is to bring up a 1.25 cluster and import it into Rancher - we'll need that for dev/testing.
The version number should be a text box, so the user can enter any version number - I don't think we can easily have a lsit of all possible options. Default version text is "latest".
This shows the creation ui patterns and the changes necessary to the key/value ui pattern

Here is an example of how the alerts could look. This uses the "pod_security" icon from the SUSE icon set (https://eos-icons.com/?iconName=pod_security&type=static).

https://xd.adobe.com/view/7d2d1b4d-4d4f-420c-b2d8-2271839a4727-287e/
Some notes as reminder:
- Exceptions are displayed only on pod creation as separated resource within the Cluster Manager
- Icon in the error/warning needs to be bound to the existing map and extend the banner component
- Border for the Labels tab content should be exceptional for this case and not global
- Username in exceptions have no autocomplete for this iteration
- Namespace have no autocomplete as are not created at this stage yet
-
Labelsmeans the currentLabels and Annotationtab
Related backend work on k8s 1.25 support, including the proposed design for the CRD and appropriate fields: https://github.com/rancher/rancher/issues/38701
/shell/plugins/steve/hybrid-class.jsget labels()is used by the Labels component and has the code that omits some of them. for the state of an existing resource,/shell/plugins/dashboard-store/resource-class.jseverything that revolves aroundstateObj, in particularstateDisplay/stateDescription, stateIcon, stateBackground, stateColor, etc
The tab in the UI should be named "Pod Security Standards", the titles on the page should be "Pod Security Configuration" (instead of the current "Pod Security Admission" in the mockup) and "Exceptions"
@kwwii should I add the SUSE icon to the Rancher icon? I can see that we are adding the resource PSA but in the design we finally have 3. Are these going to vary in length based on the resource? In the table how are these going to be recognized?
@nwmac I have been creating a pod.security.admission as list, edit and model, name TBD. In the edit I do not have the title, in the list is not showing at all due some error for the missing model and in the model I have no idea which one to extend: Norman, Steve, Workload, etc. I have no idea when to use which one.
We should add all these as documentation for the resources, possibly in a more practical approach.
Another case would be also how to customize the table cell, but probably this should have an example in the styleguide since it's a component.
The tab in the UI should be named "Pod Security Standards", the titles on the page should be "Pod Security Configuration" (instead of the current "Pod Security Admission" in the mockup) and "Exceptions"
Why do we have inconsistent names? Also how is going to be called in the sidenav of the cluster manager?
The names are intended to reflect the naming in the k8s docs. As I understand it, we have "standards" which are defined by a "configuration" which can include "exceptions". The "admission" is used in connection with the controller, afaict
@cnotv I don't quite understand your question about the icons. Can you explain?
In order to have the icon, I must add it to the other repository, is that correct? Should I make a separated PR request or what?
@cnotv yes, you will need to add the icon to the icon repo (as I understand it at least)
Ok, here's the PR https://github.com/rancher/icons/pull/44
@kwwii should we not maybe use this toggler for the show/hide labels? https://rancher.github.io/storybook/?path=/story/components-form-toggleswitch--toggle-switch

@cnotv Yes, that it is a good idea
Please refer to this issue for technical specifications and requirements: https://github.com/rancher/dashboard/issues/7176#issuecomment-1284718619 FYI @nwmac @kwwii
@jiaqiluo What will happens to the current labels and annotations which we have everywhere? In the current design the annotations are removed, is that matching the initial requirement or I am mixing things up?
@nwmac do we know which label is of type system which require to be disabled/hidden? Is this in somehow connected to the system-namespaces?
@jiaqiluo What will happens to the current labels and annotations which we have everywhere? In the current design the annotations are removed, is that matching the initial requirement or I am mixing things up?
hi @cnotv , do you mean the labels annotations currently used for PSP? It is expected to see those removed from the objects by the backend on 1.25 clusters. Please correct me if I misunderstand your question.
@jiaqiluo we currently have them for both Deployment (Workload type) and Pod configuration of our Workloads, e.g.:
@cnotv Oh, I see what you mean now. We should still support setting the labels and annotations on deployment or pod, they are separate features unrelated to the PSA.
In the current design the annotations are removed,
I never hear about this, it might be some miscommunication somewhere, but UI should keep the existing support for labels and annotations.
@jiaqiluo ok, so does it mean that this new label is going to be displayed only for Namespaces and Projects editors? Should we keep the other Label and Annotation?
If also this information is wrong, could you please define where should this view be added, on top of the resource itself?
Summary of the clarification:
- PSA are going to be added to Namespace editor tab and optionally to Projects, if ready
- The labels will display the PSA values and be protected, but values can be hardcoded, based on specification
- The Namespace detail, if contains a label of type PSA, it should be mapped in a nice way
- Workload creation should return a warning on save and should be displayed in a growl
- PSA should be added as new Rancher resource and listed in the Cluster Management, allowing users to create templates
- Inside the Cluster editor
- If Kubernetes version is >=1.25 it should hide the current PSP dropdown and show the PSA dropdown
- The PSA template will be displayed with the list of resources by name, default value empty
- The dropdown values needs to be changed on version change with the default values
Also based on the current development, the Label component should not be used as it applies everywhere.
@kwwii I have a case where if we type values which make the field disable and impossible to remove, the user will be stuck with that. What's your idea about it to prevent it?
Also what if a user writes the value on his own in the labels, e.g. pod-security.kubernetes.io/enforce and 1.1.1?
Namespace PSA are easily removable by deselecting the checkbox. The values should not persist if the user has deselected the checkbox.
Cluster PSAs are NOT removable once the cluster has been provisioned.
If the user enters enters these under labels and not as a PSA I would only expect the UI to show them when the user enters them, and if the "show/hide" is set to show. This means that if the user has the system labels set to hidden, and enters a PSA as label instead of as a PSA, the UI would still hide these labels, only showing them when the user selected "Show system labels".
This is what I mean:
https://user-images.githubusercontent.com/5009481/204484530-2fc9ccf3-e244-4644-b446-50917b5023c2.mov
This is with the integrated view:
https://user-images.githubusercontent.com/5009481/204515565-23ddd3c0-c64c-49a8-bff1-4b5337df4c3e.mov