feature: Sync Pod Security Admission Labels and OpenShift SCCs

[adambkaplan]

Feature Description

Many users of Tekton/Pipeline Service run containers that require some level of extra pod security permissions. For instance, running buildah in a container requires (at minimum) the SET_FCAP capability, which is only allowed by the baseline Pod Security Standard.

To run these workloads, the following abilities are needed:

• Set/sync the Pod Security admission labels on namespaces.
• Create/sync Security Context Constraints for OpenShift.

Proposed Solution

• Sync labels on namespaces. This may pose a security risk if users are allowed to bypass controls that limit the enforced pod security standard.
• Sync OpenShift Security Context Constraints. There are similar security risks/concerns here.

Alternative Solutions

The current solution employed by the Pipeline Service is unique to its deployment topology:

• APIs are created on the workload cluster through the OpenShift Pipelines Operator.
• KCP Syncer is used to create the APIExport (for the first cluster) back to KCP.
• Pipelines Operator creates a default service account for Tekton TaskRuns (pipelines), which have the RBAC necessary for most Tekton Tasks.
• Pipelines Operator also creates an SCC for the pipelines service account. RBAC is created to use this special SCC.

Want to contribute?

• [ ] I would like to work on this issue.

Additional Context

No response

[sttts]

Syncing labels for PodSecurity is certainly feasible but clearly needs deeper thoughts. @s-urbaniak has lots of background.

SCCs I think are out of scope for syncing. SCCs are cluster-wide and they can influence overall physical cluster behaviour. Hence, they must be pre-installed in the physical cluster outside of syncing, e.g. by some OpenShift-aware syncer operator / installer, or other kind of fleet management.

[ncdc]

Action item: let's schedule a dedicated meeting to discuss this with @s-urbaniak @adambkaplan @sttts

[ncdc]

cc @cathaloconnorrh

[s-urbaniak]

As discussed in Slack, the current state of the discussion is:

1. SCC configuration is better left as a manual exercise on the target cluster.
2. Pod Security settings will be auto-configured using the autolabelling mechanism as per https://github.com/openshift/enhancements/blob/master/enhancements/authentication/pod-security-admission-autolabeling.md

One can opt out of autolabelling (see https://docs.openshift.com/container-platform/4.11/authentication/understanding-and-managing-pod-security-admission.html#security-context-constraints-psa-opting_understanding-and-managing-pod-security-admission).

[s-urbaniak]

• Generally: An upstream (kcp) service account should be created in kcp and will be subject of the syncer synced to a downstream (OpenShift) cluster.
• The upstream (kcp) service account should be granted access to have use permissions for privileged SCCs. This RBAC lives in the downstream (OpenShift) cluster.
• When it comes to pod security admission, the granted privileged SCC should then be subject of the label syncer. Pod Security namespace labels are automatically created and adjusted by the OpenShift label syncer mechanism.

[mjudeikis]

/transfer-issue contrib-tmc