Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Understanding OpenShift Security Context Constraints

October 21, 2016
Alessandro Arrichiello
Related topics:
SecurityKubernetesContainersDevOps
Related products:
Red Hat OpenShift Container Platform

Share:

    OpenShift gives its administrators the ability to manage a set of security context constraints (SCCs) for limiting and securing their cluster. Security context constraints allow administrators to control permissions for pods using the CLI.

    SCCs allow an administrator to control the following:

    1. Running of privileged containers.
    2. Capabilities a container can request to be added.
    3. Use of host directories as volumes.
    4. The SELinux context of the container.
    5. The user ID.
    6. The use of host namespaces and networking.
    7. Allocating an 'FSGroup' that owns the pod’s volumes
    8. Configuring allowable supplemental groups
    9. Requiring the use of a read only root file system
    10. Controlling the usage of volume types
    11. Configuring allowable seccomp profiles

    Note: For managing SCC you should have cluster-admin privileges.

    By default six SCCs are added to the cluster, and are viewable by cluster administrators using the CLI:

    • anyuid
    • hostaccess
    • hostmount-anyuid
    • nonroot
    • privileged
    • restricted

    The default Security Context is 'restricted' that secure in various different ways the final running pod. Let's take a deep look into it:

    [alex@freddy ~]$ oc describe scc restricted
    Name: restricted
    Priority: <none>
    Access:
    Users: <none>
    Groups: system:authenticated     [1]
    Settings:
    Allow Privileged: false     [2]
    Default Add Capabilities: <none>
    Required Drop Capabilities: SETUID,SETGID,KILL,MKNOD,SYS_CHROOT     [3]
    Allowed Capabilities: <none>
    Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,secret      [4]
    Allow Host Network: false     [5]
    Allow Host Ports: false
    Allow Host PID: false
    Allow Host IPC: false
    Read Only Root Filesystem: false     [6]
    Run As User Strategy: MustRunAsRange     [7]
    UID: <none>
    UID Range Min: <none>
    UID Range Max: <none>
    SELinux Context Strategy: MustRunAs     [8]
    User: <none>
    Role: <none>
    Type: <none>
    Level: <none>
    FSGroup Strategy: MustRunAs     [9]
    Ranges: <none>
    Supplemental Groups Strategy: RunAsAny     [10]
    Ranges: <none>

    We can proceed analyzing it looking at the various numbers I placed over the previous list:

    1. Groups: this represent who's allowed using this SCC.
    2. Allow Privileged: just a boolean for enabling/disabling privileged container execution.
    3. Required Drop Capabilities: Any dropped capabilities, applied to the final running container.
    4. Allowed Volume Types: A list of the allowed volumes that the pod could actually mount. All the volume's types don't explicitally listed here will be denied.
    5. Allow Host Network: a boolean for enabling/disabling the view of the host network to the final container
    6. Read Only Root Filesystem: just a boolean for enabling or disabling read-only fs.
    7. Run As User Strategy: User IDs are constrained being set to MustRunAsRange. This forces user ID validation. (Other values: RunAsAny or MustRunAs)
    8. SELinux Context Strategy: A SELinux label is required (fot MustRunAs), which uses the project’s default label.
    9. FSGroup Strategy: fsGroup defines a pod’s "file system group" ID, which is added to the container’s supplemental groups.
    10. Supplemental Groups Strategy: The supplementalGroups ID applies to shared storage, whereas the fsGroup ID is used for block storage.

    The other available SCCs let cluster admins to have a set of ready to use templates for enabling ServiceAccounts to run pods with some or full of privileges. Service accounts provide a flexible way to control API access without sharing a regular user’s credentials.

    In the following paragraphs I'll describe all the necessary steps for editing existing SCCs and properly using ServiceAccounts to run existing containers.

    Please note: editing SCCs may expose your hosts to security risks, please ensure to run only validated/secured containers on your OpenShift cluster.

     

    Example: Running the official WordPress container

    Supposing you want to run in your OpenShift platform the official WordPress container, you'll rapidly discover that the container will keep failing because of lack of privileges.

    Please note: in the following example I'll use an already configured mysql server listening at address 192.168.122.1, change it according to your settings.

    [alex@freddy ~]$ oc new-project wordpress
    Already on project "wordpress" on server "https://192.168.123.1:8443".
    [alex@freddy ~]$ oc new-app -e WORDPRESS_DB_HOST=192.168.122.1 -e WORDPRESS_DB_PASSWORD=secret docker.io/wordpress
    --> Found Docker image f3cd009 (7 days old) from docker.io for "docker.io/wordpress"

    * An image stream will be created as "wordpress:latest" that will track this image
    * This image will be deployed in deployment config "wordpress"
    * Port 80/tcp will be load balanced by service "wordpress"
    * Other containers can access this service through the hostname "wordpress"
    * This image declares volumes and will default to use non-persistent, host-local storage.
    You can add persistent volumes later by running 'volume dc/wordpress --add ...'
    * WARNING: Image "docker.io/wordpress" runs as the 'root' user which may not be permitted by your cluster administrator

    --> Creating resources with label app=wordpress ...
    imagestream "wordpress" created
    deploymentconfig "wordpress" created
    service "wordpress" created
    --> Success
    Run 'oc status' to view your app.
    [alex@freddy ~]$ oc get pods
    NAME READY STATUS RESTARTS AGE
    wordpress-1-10ojk 0/1 Error 0 5s
    [alex@freddy ~]$ oc logs wordpress-1-10ojk
    chown: changing ownership of 'wp-config.php': Operation not permitted

    Taking a look to the official container on DockerHub we can verifiy that the container expects to execute as "root" user and it expects to run a listening httpd on port 80:

    [alex@freddy ~]$ docker inspect docker.io/wordpress | grep -i port -A2
    "ExposedPorts": {
    "80/tcp": {}
    },
    --
    "ExposedPorts": {
    "80/tcp": {}
    },

    The most clear and secure way to give some privileges to an OpenShift pod is via  the existing "anyuid" Security Context Constraints amd a ServiceAccount.

    Let's first create a Service Account:

    [alex@freddy ~]$ oc create serviceaccount wp-sa
    serviceaccount "wp-sa" created

    Then we can edit the "anyuid" Security Context, adding the just created ServiceAccount to the list of the allowed user to access it. We need to add to the SCC the following field:

    users:
    - system:serviceaccount:wordpress:wp-sa

    For editing a Security Context we have to login as cluster admin and then proceed:

    [alex@freddy ~]$ oc login -u system:admin
    Logged into "https://192.168.123.1:8443" as "system:admin" using existing credentials.

    [alex@freddy ~]$ oc edit scc anyuid
    securitycontextconstraints "anyuid" edited

    Ok, we're now ready for the last step, we can now edit the DeploymentConfig for using the just created ServiceAccount, adding the following field into the containers section:

    spec:
      template:
       spec:
         containers:
           serviceAccount: wp-sa
           serviceAccountName: wp-sa

     

    For editing the DeploymentConfig we have to login back as standard user and then proceed:

    [alex@freddy ~]$ oc login
    Authentication required for https://192.168.123.1:8443 (openshift)
    Username: developer
    Password:
    Login successful.

    You have one project on this server: "wordpress"

    Using project "wordpress".

    [alex@freddy ~]$ oc edit dc/wordpress
    deploymentconfig "wordpress" edited

    [alex@freddy ~]$ oc describe dc/wordpress
    Name: wordpress
    Namespace: wordpress
    Created: 2 hours ago
    Labels: app=wordpress
    Annotations: openshift.io/generated-by=OpenShiftNewApp
    Latest Version: 2
    Selector: app=wordpress,deploymentconfig=wordpress
    Replicas: 1
    Triggers: Config, Image(wordpress@latest, auto=true)
    Strategy: Rolling
    Template:
    Labels: app=wordpress
    deploymentconfig=wordpress
    Annotations: openshift.io/container.wordpress.image.entrypoint=["docker-entrypoint.sh","apache2-foreground"]
    openshift.io/generated-by=OpenShiftNewApp
    Service Account: wp-sa
    ...

     

    Now let's check that the container is up & running thanks to the Service Account and the new Security Context:

    [alex@freddy ~]$ oc get pods
    NAME READY STATUS RESTARTS AGE
    wordpress-2-8vxn2 1/1 Running 0 50s
    [alex@freddy ~]$ oc logs wordpress-2-8vxn2
    WordPress not found in /var/www/html - copying now...
    Complete! WordPress has been successfully copied to /var/www/html
    AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.4. Set the 'ServerName' directive globally to suppress this message
    AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.4. Set the 'ServerName' directive globally to suppress this message
    [Fri Oct 14 16:15:12.725438 2016] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.10 (Debian) PHP/5.6.26 configured -- resuming normal operations
    [Fri Oct 14 16:15:12.725513 2016] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

    That's all!

    Interested on improving the DeploymentConfig? Do you want to deploy a mysql server pod?

    Take a look to a ready-to-use template that I wrote: http://wordpress.inmyopenshift.cloud

     

    Feel free to leave comments with any question you may have!

     

     

     

    Recent Posts

    • How Trilio secures OpenShift virtual machines and containers

    • How to implement observability with Node.js and Llama Stack

    • How to encrypt RHEL images for Azure confidential VMs

    • How to manage RHEL virtual machines with Podman Desktop

    • Speech-to-text with Whisper and Red Hat AI Inference Server

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue