DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Pulling Images from External Container Registry to OpenShift Cluster via ImageStream
  • How to Understand and Set Up Kubernetes Networking
  • A Practical Guide for Container Security
  • Auditing Tools for Kubernetes

Trending

  • Monkey-Patching in Java
  • Securing Your Applications With Spring Security
  • How To Optimize Feature Sets With Genetic Algorithms
  • Creating a Deep vs. Shallow Copy of an Object in Java
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Understanding OpenShift Security Context Constraints

Understanding OpenShift Security Context Constraints

In this article, we take a look at Security Context Constraints (SCCs), give some examples, and show how to work with them in a container.

Alessandro Arrichiello user avatar by
Alessandro Arrichiello
·
Apr. 20, 17 · Tutorial
Like (3)
Save
Tweet
Share
8.00K Views

Join the DZone community and get the full member experience.

Join For Free

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’ in several different ways, thus securing the final running pod. Let’s take a deeper 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 to analyze it by looking at the various numbers I placed over the previous list:

  1. Groups: this represents who’s allowed to use 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 that are not explicitly 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 and set to MustRunAsRange. This forces user ID validation (other values: RunAsAny or MustRunAs).
  8. SELinux Context Strategy: An SELinux label is required (for 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 have a set of ready-to-use templates for enabling ServiceAccounts to run pods with partial or full 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 the official WordPress container in your OpenShift platform. 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 at the official container on DockerHub, we can verify 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 clearest and most secure way to give some privileges to an OpenShift pod is via the existing “anyuid” Security Context Constraints and 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 users allowed 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 log in as a 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, now we’re ready for the last step. We can now edit the DeploymentConfig for using the newly 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 log back in as a 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 and 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 in improving the DeploymentConfig? Do you want to deploy a MySQL server pod?

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

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

security OpenShift Container cluster pods Host (Unix) Template

Published at DZone with permission of Alessandro Arrichiello, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Pulling Images from External Container Registry to OpenShift Cluster via ImageStream
  • How to Understand and Set Up Kubernetes Networking
  • A Practical Guide for Container Security
  • Auditing Tools for Kubernetes

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: