Allow CSV to define PodSecurityPolicies (or Openshift SecurityContextConstraints)

[RyuunoAelia]

Feature Request

Is your feature request related to a problem? Please describe. Some platforms (and probably more and more) are restricting pods to avoid exiting the containers. A good example of that is OpenShift. In that case, some Operators might need to define custom security rules because the ones provided by the platform are too restrictive. The current status is that each operator will have to define a way to do it by either:

• asking the user to do it as a prerequisite (error prone, a hassle if there are updates to the rights for each version, etc)
• requesting the rights in RBAC to do it itself
• having another operator doing it beforehand (this is actually what Red Hat chose to do in OpenShift Container Storage : https://github.com/openshift/ocs-operator/blob/master/pkg/controller/ocsinitialization/sccs.go )

The problem here is that there is no standard way to do it, and, specially for the two last solutions, there is no easy way to understand the real rights needed by the operator (without even considering the possibility of bug that could break pre-defined PSP/SCC in the cluster).

Describe the solution you'd like Having a section of the CSV defining the PSP/SCC needed by the Operator, there would be the following advantages:

• an easy way to review the actions the operator is able to perform.
• no need for an external setup step on clusters that have these security features in enforcing mode.
• standardise the ecosystem, which is a benefit for the community as a whole.

[exdx]

We are working to add support for PSPs in the operator bundle in 4.6 - see #1564

[RyuunoAelia]

This is not exactly what I see in the PR pointed here. I do see that it is a design doc for adding new objects in the CSV, but it specifically mentions 3 Kinds and not PSP or SCC.

[exdx]

This is not exactly what I see in the PR pointed here. I do see that it is a design doc for adding new objects in the CSV, but it specifically mentions 3 Kinds and not PSP or SCC.

That's correct, my mistake. PSP was something else we looked at but is not included in that particular design. However, we are looking to add support for all arbitrary kube objects in the bundle in the upcoming releases of OLM - we know this is an important feature for the community.

[cdjohnson]

I want to second the importance of this feature as it's important to be able to define custom PSPs/SCCs to tighten privileges for pods as much as possible and avoid using pre-defined policies that may be scoped too large, may have been modified, or may have been removed.

Having a user manually create well-named PSPs/SCCs prior to installing an operator and the associated ClusterRole/Bindings prior to installing the operator is obviously problemmatic.

@exdx I'm assuming you're talking about the csv-less bundles feature.

One aspect that's important to include in either design is the Conditional nature of some resources. PSPs can be installed on OpenShift, but they are ignored. SCC's can ONLY be installed on OpenShift as the API doesn't exist elsewhere.

@njhale Is this scenario covered in csvless-bundles?

[RyuunoAelia]

My personal fear is auditing the rights an operator need, before installing it. As of now, all the rights the operator need are present in the CSV, if real arbitrary objects can be created by placing them into the manifest directory then you need to unpack the bundle to see what rights the operator will need. This becomes even more dangerous if the bundle can contain PSP/SCCs. The current way Red Hat decided to work-around the issue (for Red Hat Openshift Container Storage) is creating another operator that has an awful lot of permissions that will create the SCC to run the ceph operator. From a security perspective it is less than ideal (even if the SCCs are static).

If the CSV contains the SCC/PSP information too, it becomes easier to audit. Moreover as I understand csv-less bundles, a CSV will be generated automatically from the manifest/metadata information, so I can don't see an issue with this way of handling the SCC/PSP.

Correct me if I am missing something or wrong in any way.

[exdx]

We are tracking this RFE at https://issues.redhat.com/browse/RFE-781. There are some details there that we considered when initially considering adding support for PSPs in 4.5.

@cdjohnson that's a good point, the difference between PSPs and SCCs. I'm not familiar with SCCs, where can I find more information on them? They seem like OpenShift specific PSPs. Ideally we need to support both.

@RyuunoAelia I like your idea about putting the SCC/PSP information directly in the CSV. However, our long term vision right now is to move away from the CSV entirely - from the user not having to include one in the bundle (and generating a CSV for free on the client side via opm), to eventually generating a CSV only at runtime on the OLM side, to ultimately having OLM manage and install objects directly from the bundle without the need for a CSV. So increasing the spec of the CSV doesn't fit into these plans, although it does make sense if we wanted to keep the CSV API long-term.

Your point about unpacking the objects in the bundle to determine the permissions an operator needs are spot on. This is one of the big challenges of OLM - to provide a package manager experience (a la Helm) while still being responsible for the lifecycle and stability of clusterwide operators and the cluster itself. It's an area that we are actively investigating alongside the operator scoping problem @njhale and @ecordell are looking at.

[cdjohnson]

@exdx Sadly, mostof us (including me) can't see that issue. Shouldn't that really be in an enhancement markdown in the enhancements repo?

SCC == SecurityContextConstraint. It's the core technology that PSPs were designed from (I think). Link to docs. So, yes, it provides the same capability as PSPs, with some other goodies.

[RyuunoAelia]

If we are playing spot the differencies between openshift and kubernetes we have a lot to point.

• SCC vs PSP
• Route vs Ingress
• (at least for openshift 3.x) RBAC resources are in apiVersion authorization.openshift.io/v1 versus rbac.authorization.k8s.io/v1

probably other stuff I don't know about.

I think that simply saying that objects are in the bundle and OLM will create them as-is poses a lot of issues for compatibility between different versions of OpenShift and kubernetes.

This goes farther than simply the differences between OpenShift and kubernetes, but also the apiVersion changes between versions of kubernetes.

I also see another big issue for naming, as objects like PSP/SCC are cluster-wide, there is a risk of name collision. Changing the name of PSP/SCC by putting a random string like it is currently done for ClusterRoles, implies that OLM fully understands the usages of the object and controls the references of each usage.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cdjohnson]

bump

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.