Introducing the Security Profiles Operator for OpenShift

Security remains the #1 funding priority for IT technologies across organizations from almost every industry, according to our latest Global Tech Outlook 2023 report. The same report also found cloud security as the #1 funding priority among all cloud infrastructure spend. Security even ranked number #1 as the overall priority for digital transformation initiatives, outranking innovation and further underscoring the importance of security for digital transformation.

Question 2.2: If you were to characterize your absolute top priority for your company's digital transformation in a single term, which of the following would best fit?

At Red Hat, we have continued our commitment to innovation and security, promoting growth through technologies to not just build and manage modern applications, but also help organizations address the security challenges in cloud native environments. From acquiring StackRox, a Kubernetes security company, in 2020, to open sourcing the underlying StackRox platform, and conceiving and prototyping Sigstore  – an open source project for software supply chain security – Red Hat is committed to helping organizations more securely transform their business using cloud native technologies.

Today we’re excited to announce the general availability of the Security Profiles Operator (SPO) for Red Hat OpenShift, our latest in security innovation. OpenShift 4.12 brings with it several new security enhancements to help improve customer security posture and further harden their environments, and SPO is one of the security highlights of our update.

With this update, Red Hat aims to provide an even more resilient, security-focused foundation, and trusted technology so that customers can turn their focus to building, managing, and controlling hybrid environments, while developing robust cloud native applications without sacrificing security.

What is Security Profiles Operator

Security Profiles Operator is an open source project, developed by the Kubernetes community (including Red Hat), to help address some of the challenges of applying security hardening using capabilities such as SELinux, seccomp or AppArmor profiles. Specifically, SPO helps solve the problems associated with creating and managing granular policies to protect workloads in a Kubernetes cluster.

What are SELinux and seccomp profiles?

Security hardening is a cornerstone of building secure applications, and it’s one of the first steps you should take to shift security left and protect your environment. Security Enhanced Linux, or SELinux, is a Linux kernel security module that enforces Mandatory Access Control (MAC).

Every process and system resource has a special security label called an SELinux context, also known as SELinux label. SELinux labels provide a consistent way of identifying objects in the SELinux policy. An SELinux policy consists of rules which determine how processes can interact with each other and the various system resources. In other words, SELinux provides a critical layer of system security by answering the question “Can a subject perform specific action on a given object?” By default, the policy operates in a deny-all mechanism unless a rule explicitly grants access.

However, there isn’t an easy mechanism to write a custom SELinux policy that allows only what’s needed because the policy must first be written, then deployed to the nodes and then installed. This results in developers taking the easier and faster path of simply running privileged containers and disabling SELinux (and seccomp) protections.

Seccomp, also known as secure computing mode, is a security feature built into the Linux kernel. It allows you to limit the system calls that processes inside a container can make to only those that are needed for the application to operate. This reduces the risk of containers running with unnecessary privileges and allowed system calls, in adherence with the principle of least privilege.

Red Hat OpenShift, for example, applies the default seccomp profile runtime/default and sets the Security Context Constraints (SCC) to restricted-v2 for all newly created pods which prevents privilege escalation. Like SELinux, custom Seccomp profiles can be prohibitively difficult to create. Developers may end up disabling the default Seccomp profile when the application fails at runtime due to overly restrictive syscall defined by the default seccomp profile. This might speed up development but at the expense of security.

Key benefits and use cases for SPO

Profile distribution

Custom resources for seccomp and SELinux profiles

Traditionally, an administrator had to create the seccomp profiles as flat files and distribute them to the nodes. In case of SELinux, the administrator would have to additionally install the profiles with a one time systemd policy. With Red Hat OpenShift, modifying files on the cluster often requires a restart. It's also difficult to keep track of the files or delegate creation of the profiles with RBAC unless they’re exposed as custom resources. Managing the profiles as custom resources provides the benefit of observability (the resource has a .status subresource) and allows you to easily inspect which profiles are available or in use. Administrators can then readily see if the profile is ready to use or already in use, whether there are syntax errors, what is its status per node, and whether it can be safely removed.

• The profiles can be marked as “permissive” or use the “SCP_ACCT_LOG” action so that they only log policy violations without actually enforcing them. The action can then be changed to enforce the policy once the profile has been deemed stable.
• Another beneficial property of the SELinux profiles is that the custom resource exposes a YAML representation of the profile that is then converted into the SELinux CIL language at install time. This is important because the SPO custom resource representing the SELinux policy is much easier to read, as the below side-by-side example shows.

SPO CRD format:
spec:
  allow:
     '@self':
        tcp_socket:
        - listen
     http_cache_port_t:
        tcp_socket:
        - name_bind
     node_t:
        tcp_socket:
        - node_bind
  inherit:
  - kind: System
    name: container

CIL (SELinux native format):
(block nginx-secure_nginx-secure
(blockinherit container)
(allow process nginx-secure_nginx-secure.process ( tcp_socket ( listen )))
(allow process http_cache_port_t ( tcp_socket ( name_bind )))
(allow process node_t ( tcp_socket ( node_bind )))
)

Automatically deploy profiles into all nodes

Instead of creating and deploying the profiles manually, using the profiles as CRs means that as the cluster scales up/down, the profiles are added to all nodes. In addition, removing the profiles becomes easier as well because a profile file will not be accidentally forgotten.

Bind profiles to workloads by using custom resource definitions (CRDs)

With the ProfileBinding customer resource, the administrator can link container images to security profiles. This is powered by an SPO webhook which listens to namespaces labeled with a special label and ProfileBinding objects inside those namespaces (downstream docs, upstream docs).

Profile composition - profiles can inherit from other profiles

This is useful for composing profiles from profile building blocks. An example is a generic profile for the container runtime on the cluster and then the profile in use just adds the syscalls the application needs. (downstream docs, upstream docs for seccomp, downstream docs, upstream docs for SELinux)

Restrict seccomp profiles to a subset of system calls

To make sure no user-created profiles allow more than what the administrator sets, it is possible to create a set of syscalls that the profiles are allowed to make (downstream docs, upstream docs).

Profile recording

Automate policy creation

Instead of hand-crafting the policy, the user can create a ProfileRecording object in the namespace where the application to be recorded will run, then run the application while SPO collects the system calls or AVC denials and produces a seccomp or SELinux policy automatically, with minimal user input or expertise required. The profile recorder can also merge policies produced by different instances of an application container into one resulting policy. What this means is that if you record an application that is scaling up and down during the test or different replicas of the application are doing different things while being recorded, then the resulting policy will be based on a combination of all the calls the app has done without having to manually merge many small policies (downstream WIP, upstream).

Automatically creating policies using profile recording (and combining policies) saves time and developer resources. The application developers don't have to know how to create security profiles. All they need to do is run the application while a ProfileRecording is in the application namespace and a policy will be generated for them.

The primary use-case we had in mind is that the policy would be recorded in a “sandbox” or a CI system and then deployed into production, perhaps first in a permissive or complain mode (SCP_ACCT_LOG for seccomp, permissive: true for SELinux) and then enabled/enforced.

Observability

• Metrics about profile usage - when installed through the Red Hat catalog, the metrics are automatically visible through Prometheus and the administrator can see how many profiles have been installed, updated etc.
• Audit log enrichment for easier parsing, including metrics - the primary use of the log enricher is for profile recording, but the administrator can also use the enricher to observe an application

In addition to making Security Profiles Operator generally available, Red Hat OpenShift 4.12 delivers several other security-focused enhancements that will help developers and operators better achieve their security and compliance goals. To learn more about these and other product updates, check out the release notes for OpenShift 4.12.