Security Profiles Operator Proposal

 

Assorted

• MCO deps to deploy the selinux/seccomp profiles w/o rebooting
• Clearly mark that development of profiles or profile recording is out of the 4.9 scope

Problem Statement

At the time of writing (4.7) there are approximately 164 containers running in privileged-mode in a default OpenShift deployment (no add-ons). None of the containers we provide is using Seccomp nor SELinux to limit the attack surface of the containers. This opens up those workloads as valuable targets for exploitation. The same applies to third-party operators.

 

Even though the platform and the container runtimes themselves have support for applying Seccomp or SELinux profiles, it is hard to actually deploy them in a k8s-centric manner, manage them, see their status or develop the profiles. We need to lower the bar to locking down workloads that run on OCP, thus making the whole platform more secure.

 

Security Profiles Operator (SPO) is an upstream project that aids in the development, deployment, and administration of security profiles like Seccomp or SELinux. The proposal is to include SPO in OpenShift to help with managing and applying security profiles in OpenShift.

Proposal

We intend to productize the Security Profiles Operator as a joint effort between the Infrastructure Security & Compliance team, and the Node team. Initially, the operator would support management of security profiles, future releases would focus also on development of security profiles so that these profiles could be used by the single source of truth by both developers and ops/sec.

Roadmap

4.9

The operator will be delivered in OperatorHub as a first step, enabling administrators to install it as a day two operation. This deliverable will cover the base use cases for the lifecycle management of security profiles. Any extra functionality (e.g. profile recording) will be considered tech preview and not be formally supported.

 

4.10

The Security Profiles Operator will be enhanced with addons to usability. Developers will be able to take the profile recording feature into use. We can also work on gathering sample profiles for people to use: e.g. profiles that allow deployment web-servers like Apache or Nginx.

4.11

Productization of the log enrichment feature: correlating audit logs with the relevant pod and profile.

Future

Based on feedback, we’d like to make the operator be a central part of OpenShift and be deployed in clusters by default. This will allow the Red Hat developer community and partners to rely on the abstractions provided by the operator to secure their workloads.

 

Appropriate SCCs should be introduced to easily allow workloads to have custom Seccomp and SELinux profiles, while still disallowing the workload to be privileged.

 

We could, in the future, point partners to the operator and incentivize them to provide their operators with appropriate security profiles alongside their workloads.

 

The CTO office is starting to work on Linux capabilities discovery/recording; this work could be included in the Security Profiles Operator.

Personas

These personas are the potential users of the security-profiles-operator. The intent of the operator is to address the needs of these personas, and so, user stories and feature enhancements shall be targeted at helping them.

Infrastructure SRE (infra/host)

Kirsti

Responsible for Day 1 and Day 2 operations for the infrastructure:

• This includes security operations
• Has a more technical dashboard view of the state of security
• Wants compartmentalization verification
• Namespaces, Seccomp, and SELinux technical reports

Application SRE (tenant/workload)

Rajesh

Responsible for:

• Application deployment, maintenance, and monitoring.

Interacts with:

• Application developer for...
• Infra SRE for...

Desires:

• No security events/breaches related to managed applications.
• Easy way to ensure the applications they are responsible for are configured securely.

Application Developer

Ming

Responsible for:

• Development of new container-native applications.
• Modernizing legacy applications to be moved from bare-metal or virtualized environments to container platforms.
• Developing applications that meet the security requirements.

Interacts with:

• Application SRE to support application deployment, maintenance, and development of new functionality.
• PM, Compliance Officer, or someone else to understand security requirements imposed on their application(s) for the target deployment environment(s).

Desires:

• Easily meet security requirements that are built into the development process without requiring expertise in security components.
• Development environments that mimic production from a security perspective to avoid surprises when applications are deployed into production.

 

Use Cases

4.9

As an application SRE, Rajesh would like to deploy a Seccomp profile and SELinux profiles to secure their application.

Details:

• This would also apply to Ming, as an application developer would be deploying to a development environment.

As an application developer, Ming would like to be able to debug and develop their security profiles using similar tools as would be used to deploy the app in production.

Details:

• Ming needs to be able to try out different profiles and get appropriate error messages if the profile is badly formatted. Where possible, invalid profiles should be rejected with user-friendly validation error messages and not applied to the system.

As an application developer, Ming would like to be able to debug syntax errors in a given profile.

Details:

• The operator should be able to clearly point out syntax errors that might appear in a certain profile. E.g. for SELinux a missing parenthesis or something of the sort… This is considered for SELinux in[ an issue|https://github.com/kubernetes-sigs/security-profiles-operator/issues/223]
• Note that this does not infer that the operator will offer an environment that will provide people with feedback on their syntax. The operator will merely point out issues in the CRDs.

As an application SRE, Rajesh needs to be able to see the state of the installed profile(s) and verify that it has indeed been installed on the system.

Details:

• This allows for auditing of what profiles are installed in the system and in what namespace are they.

4.10

As an application developer, Ming would like to be able to automatically generate initial security profiles that are specific to the application.

4.11

• Log enrichment