DO280 - ch10s03

Bookmark this page

P 1 2 3 4 5 6 7 8 9 10

Lab: Secure Applications

Configure a project that requires custom settings.

Secure applications by encrypting and restricting network traffic.

Automate cluster maintenance tasks.

Outcomes

Create a project quota.
Create a limit range.
Use role-based access control to grant permissions to service accounts and groups.
Encrypt the traffic end-to-end with TLS by using a signed certificate.
Restrict cluster internal traffic to pods by using network policies.
Grant application access to Kubernetes APIs.
Configure a cluster maintenance application to run periodically.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

[student@workstation ~]$ lab start compreview-apps

The lab command copies the exercise files into the ~/DO280/labs/compreview-apps directory and creates the workshop-support group with the do280-support user. The lab command also restores the project template configuration from the previous exercise.

The goal, as a cluster administrator, is to prepare the workshop-support namespace for the support team. Create a namespace instead of a project to avoid using the project template. The project template applies a default configuration for workshop projects, and does not apply the configuration to the workshop-support namespace. Then, as a support team member, you configure and deploy the applications that maintain the cluster and support the workshop experience.

You must set up an application that automatically deletes completed workshops, and set up a social media API that attendees from all workshops use.

Specifications

Create the workshop-support namespace with the category: support label.
Grant to the workshop-support group the admin role in the cluster.
Workloads from the workshop-support namespace must enforce the following constraints:
- The project uses up to 4 CPUs.
- The project uses up to 4 Gi of RAM.
- The project requests up to 3.5 CPUs.
- The project requests up to 3 Gi of RAM.
Define the default resource specification for workloads:
- A default limit of 300m CPUs.
- A default limit of 400 Mi of RAM.
- A default request of 100m CPUs.
- A default request of 250 Mi of RAM.
Any quota or limit range must have the workshop-support name for grading purposes.
As the do280-support user, deploy the project-cleaner application from the project-cleaner/example-pod.yaml file to the workshop-support namespace by using a project-cleaner cron job that runs every minute.
The project cleaner deletes projects with the workshop label that exist for more than 10 seconds. This short expiration time is deliberate for this lab.
You must create a project-cleaner-sa service account to use in the project cleaner application.
The role that the project cleaner needs is defined in the project-cleaner/cluster-role.yaml file.
Deploy the beeper-db database in the beeper-api/beeper-db.yaml file to the workshop-support namespace.
Deploy the beeper-api application in the beeper-api/deployment.yaml file to the workshop-support namespace.
You must configure this application to use TLS end-to-end by using the following specification:
- Use the beeper-api.pem certificate and the beeper-api.key in the certs directory.
- Configure the /etc/pki/beeper-api/ path as the mount point for the certificate and key.
- Set the TLS_ENABLED environment variable to the true value.
Update the startup, readiness, and liveness probes to use TLS.
Create a passthrough route with the beeper-api.apps.ocp4.example.com hostname.
The database pods, which are pods in the workshop-support namespace with the app=beeper-db label, must accept only TCP traffic from the beeper-api pods in the workshop-support namespace on the 5432 port. You can use the category=support label to identify the pods that belong to the workshop-support namespace.
Configure the cluster network so that the workshop-support namespace accepts only external ingress traffic to pods that listen on the 8080 port, and blocks traffic from other projects.

Change to the ~/DO280/labs/compreview-apps directory and log in to the cluster as the admin user.

Open a terminal window and change to the lab directory.

[student@workstation ~]$ cd ~/DO280/labs/compreview-apps

[student@workstation compreview-apps]$ oc login -u admin -p redhatocp \
  https://api.ocp4.example.com:6443
Login successful.
...output omitted...

Create and prepare the workshop-support namespace with the following actions:

Add the category=support label.
Grant the admin cluster role to the workshop-support group.

Create the workshop-support namespace.

[student@workstation compreview-apps]$ oc create namespace workshop-support
namespace/workshop-support created

Use the oc label command to add the category=support label to the workshop-support namespace.

[student@workstation beeper-api]$ oc label namespace \
  workshop-support category=support
namespace/workshop-support labeled

Change to the workshop-support namespace by using the oc project command.

[student@workstation beeper-api]$ oc project workshop-support
Now using project "workshop-support" on server...

Create a cluster role binding to assign the admin cluster role to the workshop-support group.

[student@workstation compreview-apps]$ oc adm policy \
  add-cluster-role-to-group admin workshop-support
clusterrole.rbac.authorization.k8s.io/admin added: "workshop-support"

Create the resource quota for the workshop-support namespace with the following specification.
Quota Value
limits.cpu 4
limits.memory 4Gi
requests.cpu 3500m
requests.memory 3Gi
1. Run the oc create quota command to create the quota.
```
[student@workstation compreview-apps]$ oc create quota workshop-support \
 --hard=limits.cpu=4,limits.memory=4Gi,requests.cpu=3500m,requests.memory=3Gi
resourcequota/workshop-support created
```

Quota	Value
`limits.cpu`	`4`
`limits.memory`	`4Gi`
`requests.cpu`	`3500m`
`requests.memory`	`3Gi`

Create the workshop limit range with the following specification.

Limit type	Value
`default.cpu`	`300m`
`default.memory`	`400Mi`
`defaulRequest.cpu`	`100m`
`defaulRequest.memory`	`250Mi`

Edit the limitrange.yaml file and replace the CHANGE_ME label to match the following definition.

apiVersion: v1
kind: LimitRange
metadata:
 name: workshop-support
 namespace: workshop-support
spec:
 limits:
   - default:
       cpu: 300m
       memory: 400Mi
     defaultRequest:
       cpu: 100m
       memory: 250Mi
     type: Container

Use the oc apply command to create the limit range in the workshop-support project.

[student@workstation compreview-apps]$ oc apply -f limitrange.yaml
limitrange/workshop-support created

Create the project-cleaner-sa service account in the workshop-support namespace. Then, assign the role from the project-cleaner/cluster-role.yaml file to the project-cleaner-sa service account.

Create the project-cleaner-sa service account.

[student@workstation compreview-apps]$ oc create sa project-cleaner-sa
serviceaccount/project-cleaner-sa created

Change to the ~/DO280/labs/compreview-apps/project-cleaner directory to access the application files.
```
[student@workstation compreview-apps]$ cd \
  ~/DO280/labs/compreview-apps/project-cleaner
```

Create the project-cleaner cluster role by applying the cluster-role.yaml manifest file.

[student@workstation project-cleaner]$ oc apply -f cluster-role.yaml
clusterrole.rbac.authorization.k8s.io/project-cleaner created

Use the oc adm policy add-cluster-role-to-user command to add the project-cleaner role to the project-cleaner-sa service account.

[student@workstation project-cleaner]$ oc adm policy add-cluster-role-to-user \
  project-cleaner -z project-cleaner-sa
clusterrole.rbac.authorization.k8s.io/project-cleaner added: "project-cleaner-sa"

As the do280-support user, create the project-cleaner cron job by editing the cron⁠-⁠job⁠.⁠yaml file and by using the example-pod.yaml pod manifest as the job template. Configure the cron job to run every minute.

[student@workstation project-cleaner]$ oc login -u do280-support -p redhat
Login successful.
...output omitted...

Edit the cron-job.yaml file:

Replace the CHANGE_ME label with the "*/1 * * * *" schedule to execute the job every minute.
Replace the CHANGE_ME label in the jobTemplate definition with the spec definition from the example-pod.yaml pod manifest.

Replace the CHANGE_ME label in the serviceAccountName key with the project-cleaner-sa service account.

Although the long image name might show across two lines, you must add it as one line.

A solution file is in the ~/DO280/solutions/compreview-apps/project-cleaner/cron-job.yaml path.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: project-cleaner
  namespace: workshop-support
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          serviceAccountName: project-cleaner-sa
          containers:
            - name: project-cleaner
              image: registry.ocp4.example.com:8443/redhattraining/do280-project-cleaner:v1.1
              imagePullPolicy: Always
              env:
              - name: "PROJECT_TAG"
                value: "workshop"
              - name: "EXPIRATION_SECONDS"
                value: "10"
              resources:
                limits:
                  cpu: 100m
                  memory: 200Mi

Create the cron job.
```
[student@workstation project-cleaner]$ oc apply -f cron-job.yaml
cronjob.batch/project-cleaner created
```
Note
It is safe to ignore pod security warnings for exercises in this course. OpenShift uses the Security Context Constraints controller to provide safe defaults for pod security.

Verify that the project cleaner application is deployed correctly, by creating a clean⁠-⁠test project.

[student@workstation project-cleaner]$ oc new-project clean-test
Now using project "clean-test" on server...
...output omitted...

Change to the workshop-support namespace.

[student@workstation project-cleaner]$ oc project workshop-support
Now using project "workshop-support" on server...

Wait for a successful job run. Then, get the pod name from the last job run.

[student@workstation project-cleaner]$ oc get jobs,pods
NAME                                 COMPLETIONS   DURATION   AGE
job.batch/project-cleaner-27949859   1/1           7s         2m40s
job.batch/project-cleaner-27949860   1/1           7s         100s
job.batch/project-cleaner-27949861   1/1           6s         40s

NAME                                 READY   STATUS      RESTARTS   AGE
pod/project-cleaner-27949859-f98vj   0/1     Completed   0          2m40s
pod/project-cleaner-27949860-j8td5   0/1     Completed   0          100s
pod/project-cleaner-27949861-p262t   0/1     Completed   0          40s

Read the logs of the pod that completed the job.

[student@workstation project-cleaner]$ oc logs \
  pod/project-cleaner-27949861-p262t
Listing namespaces with label workshop:
 - namespace: clean-test, created 55.327453 seconds ago...
Deleting namespaces: clean-test
Namespace 'clean-test' deleted

Note

You might see deleted projects from other exercises in the course.

Verify that the cron job deletes the clean-test project, by using the oc get project command.

[student@workstation project-cleaner]$ oc get project clean-test
Error from server (NotFound): namespaces "clean-test" not found

Create the beeper database by applying the beeper-api/beeper-db.yaml file.

Change to the ~/DO280/labs/compreview/beeper-api directory to access the application files.
```
[student@workstation project-cleaner]$ cd ~/DO280/labs/compreview-apps/beeper-api
```

Use the oc apply command to create the database in the workshop-support namespace.

[student@workstation beeper-api]$ oc apply -f beeper-db.yaml
secret/beeper-db created
service/beeper-db created
persistentvolumeclaim/beeper-db created
deployment.apps/beeper-db created

Verify that the database pod is running by using the oc get pod command to get the pods with the app=beeper-db label.

[student@workstation beeper-api]$ oc get pod -l app=beeper-db
NAME                         READY   STATUS    RESTARTS   AGE
beeper-db-688756744f-rgxpg   1/1     Running   0          3m51s

Configure TLS on the beeper-api deployment by using a signed certificate by a corporate CA to accept TLS connections from outside the cluster.

You have the CA certificate and the signed certificate for the beeper-api.apps.ocp4.example.com domain in the beeper-api/certs directory of the lab.

Use the following settings in the deployment to configure TLS:

Set the path for the certificate and key to /etc/pki/beeper-api/.
Set the TLS_ENABLED environment variable to the true value.
Update the startup, readiness, and liveness probes to use TLS.

Create the beeper-api-cert secret by using the beeper-api.pem certificate and the beeper-api.key key from the lab directory.

[student@workstation beeper-api]$ oc create secret tls beeper-api-cert \
  --cert certs/beeper-api.pem --key certs/beeper-api.key
secret/beeper-api-cert created

Edit the beeper-api deployment in the deployment.yaml file to mount the beeper-api-cert secret on the /etc/pki/beeper-api/ path.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: beeper-api
  namespace: workshop-support
spec:
...output omitted...
    spec:
      containers:
        - name: beeper-api
...output omitted...
          env:
            - name: TLS_ENABLED
              value: "false"
          volumeMounts:
            - name: beeper-api-cert
              mountPath: /etc/pki/beeper-api/
      volumes:
        - name: beeper-api-cert
          secret:
            defaultMode: 420
            secretName: beeper-api-cert

Edit the beeper-api deployment in the deployment.yaml file to configure TLS for the application and for the startup, readiness, and liveness probes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: beeper-api
  namespace: workshop-support
spec:
...output omitted...
    spec:
      containers:
      - name: beeper-api
...output omitted...
        ports:
          - containerPort: 8080
        readinessProbe:
          httpGet:
            port: 8080
            path: /readyz
            scheme: HTTPS
        livenessProbe:
          httpGet:
            port: 8080
            path: /livez
            scheme: HTTPS
        startupProbe:
          httpGet:
            path: /readyz
            port: 8080
            scheme: HTTPS
          failureThreshold: 30
          periodSeconds: 3
        env:
          - name: TLS_ENABLED
            value: "true"
...output omitted...

Use the oc apply command to create the beeper-api deployment.

[student@workstation beeper-api]$ oc apply -f deployment.yaml
deployment.apps/beeper-api created

Edit the service.yaml file to configure the beeper-api service to listen on the standard HTTPS 443 port and to forward connections to pods with the app: beeper-api label on port 8080.

apiVersion: v1
kind: Service
metadata:
  name: beeper-api
  namespace: workshop-support
spec:
  selector:
    app: beeper-api
  ports:
    - port: 443
      targetPort: 8080
      name: https

Use the oc apply command to create the beeper-api service.

[student@workstation beeper-api]$ oc apply -f service.yaml
service/beeper-api created

Expose the beeper API to outer cluster access by using the FQDN in the signed certificate by the corporate CA.
1. Create a passthrough route for the beeper-api service by using the beeper-api.apps.ocp4.example.com hostname.
```
[student@workstation beeper-api]$ oc create route \
  passthrough beeper-api-https \
  --service beeper-api \
  --hostname beeper-api.apps.ocp4.example.com
route.route.openshift.io/beeper-api-https created
```
2. Use the curl command to the https://beeper-api.apps.ocp4.example.com/api/beeps URL to verify that the beeper API is accessible from outside the cluster. Add the --cacert option to accept the certs/ca.pem CA.
```
[student@workstation beeper-api]$ curl -s --cacert \
  certs/ca.pem https://beeper-api.apps.ocp4.example.com/api/beeps; echo
[]
```
Optionally, open a web browser and verify that you can access the API by navigating to the https://beeper-api.apps.ocp4.example.com/swagger-ui.html URL. When you see the warning about the security risk, click Advanced… and then click Accept the Risk and Continue.

Configure network policies to allow only TCP ingress traffic on port 5432 to database pods from the beeper-api pods.

Verify that you can access the beeper-db service from the workshop-support namespace by testing TCP connectivity to the database service. Use the oc debug command to create a pod with the nc command with the -z option to test TCP access.

[student@workstation beeper-api]$ oc debug --to-namespace="workshop-support" -- \
  nc -z -v beeper-db.workshop-support.svc.cluster.local 5432
Starting pod/image-debug ...
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 172.30.219.94:5432.
Ncat: 0 bytes sent, 0 bytes received in 0.02 seconds.

Removing debug pod ...

Create an entry in the database by using the following curl command.

[student@workstation beeper-api]$ curl -s --cacert certs/ca.pem -X 'POST' \
  'https://beeper-api.apps.ocp4.example.com/api/beep' \
  -H 'Content-Type: application/json' \
  -d '{ "username": "user1",  "content": "first message" }'

Edit the db-networkpolicy.yaml file so that only pods with the app: beeper-api label can connect to database pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-policy
  namespace: workshop-support
spec:
  podSelector:
    matchLabels:
      app: beeper-db
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              category: support
          podSelector:
            matchLabels:
              app: beeper-api
      ports:
        - protocol: TCP
          port: 5432

Create the network policy.

[student@workstation beeper-api]$ oc apply -f db-networkpolicy.yaml
networkpolicy.networking.k8s.io/beeper-api-ingresspolicy created

Verify that you cannot connect to the database, by running the previous nc command.

[student@workstation beeper-api]$ oc debug --to-namespace="workshop-support" -- \
  nc -z -v beeper-db.workshop-support.svc.cluster.local 5432
Starting pod/image-debug ...
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connection timed out.

Removing debug pod ...

Verify that the API pods have access to the database pods, by running the curl command to query the API by using the external route.

[student@workstation beeper-api]$ curl -s --cacert \
  certs/ca.pem https://beeper-api.apps.ocp4.example.com/api/beeps; echo
[{"id":1,"username":"user1","content":"first message","votes":0}]

Configure network policies in the workshop-support namespace to accept only ingress connections from the OpenShift router pods to port 8080.

Verify that you can access the API service from the workshop-support namespace by testing TCP connectivity. Use the oc debug command to create a pod with the nc command with the -z option to test TCP access.

[student@workstation beeper-api]$ oc debug --to-namespace="workshop-support" -- \
  nc -z -v beeper-api.workshop-support.svc.cluster.local 443
Starting pod/image-debug ...
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 172.30.32.28:443.
Ncat: 0 bytes sent, 0 bytes received in 0.02 seconds.

Removing debug pod ...

Edit the beeper-api-ingresspolicy.yaml file to accept ingress connections from router pods by adding a namespace selector with the policy-group.network.openshift.io/ingress label.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: beeper-api-ingresspolicy
  namespace: workshop-support
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              policy-group.network.openshift.io/ingress: ""
      ports:
        - protocol: TCP
          port: 8080

Create the network policy.

[student@workstation beeper-api]$ oc apply -f beeper-api-ingresspolicy.yaml
networkpolicy.networking.k8s.io/beeper-api created

Verify that you cannot access the API service from the workshop-support namespace. Use the oc debug command to create a pod with the nc command with the -z option to test TCP access.

[student@workstation beeper-api]$ oc debug --to-namespace="workshop-support" -- \
  nc -z -v beeper-api.workshop-support.svc.cluster.local 443
Starting pod/image-debug ...
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connection timed out.

Removing debug pod ...

Verify that the API pods are accessible from outside the cluster by running the curl command to query the API external route.

[student@workstation beeper-api]$ curl -s --cacert \
  certs/ca.pem https://beeper-api.apps.ocp4.example.com/livez; echo
{"status":"UP"}

Change to the home directory.
```
[student@workstation appsec-review]$ cd
```

Evaluation

As the student user on the workstation machine, use the lab command to grade your work. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab grade compreview-apps

Finish

As the student user on the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish compreview-apps

Discuss Red Hat OpenShift Administration II: Configuring a Production Cluster

Go to community

Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280)

Haley_Ruccio

26 lip 2023

Configure, manage, and troubleshoot OpenShift clusters and containerized applicationsRed Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280) prepares OpenShift Cluster Administrators to perform daily administration tasks on clusters that host applications provided by internal teams and external vendors, enable self-service for cluster users with different roles, and deploy applications that require special permissions such as such as CI/CD tooling, performance monitoring, and security scanners. This course focuses on configuring multi-tenancy and security features of OpenShift as well as managing OpenShift add-ons based on operators.The skills you learn in this course can be applied using all versions of OpenShift, including Red Hat OpenShift on AWS (ROSA), Azure Red Hat OpenShift, and OpenShift Container Platform.This course is based on OpenShift Container Platform 4.12.5-10 Course TopicsDeploying packaged applications using manifests, templates, kustomize, and helm.Configuring authentication and authorization for users and applications.Protecting network traffic with network policies and exposing applications with proper network access.Deploying and managing applications using resources manifests.Enabling developer self-service of application projects.Managing OpenShift cluster updates and Kubernetes operator updates.Target AudienceSystem Administrators and Platform Operators interested in the ongoing management of OpenShift clusters, applications, users, and add-ons.Site Reliability Engineers interested in the ongoing maintenance and troubleshooting of Kubernetes clusters.System and Software Architects interested in understanding the security of an OpenShift cluster.Recommended TrainingTake our free assessment to gauge whether this offering is the best fit for your skills.Prerequisite: Red Hat OpenShift I: Containers & Kubernetes (DO180 v4.12), or equivalent skills deploying and managing Kubernetes applications using the OpenShift web console and command-line interfaces.Technology considerationsThis course requires internet access to access the cloud-based classroom environment that provides an OpenShift cluster and a remote administrator’s workstation.

476

About pod security standards and warnings

alexcorcoles

17 kwi 2023

(This material has been created with the inputs of instructors and other people. We are trying to get this material published as soon as possible to address some concerns with DO180 and DO280.)With the default configuration, any namespace that you create on OpenShift 4.12 has the following labels: pod-security.kubernetes.io/audit: restrictedpod-security.kubernetes.io/audit-version: v1.24pod-security.kubernetes.io/warn: restrictedpod-security.kubernetes.io/warn-version: v1.24 These labels activate auditing and warning of the restricted pod security standard. The Kubernetes documentation describes the restricted pod security standard. Pod security standards such as restricted are not directly related to security context constraints such as the restricted SCC.Kubernetes uses an admission controller to reject pods that do not comply with pod security standards. An admission controller is a Kubernetes component that inspects every Kubernetes resource before its creation, and acts before Kubernetes creates the resource. This action can include rejecting the creation of the resource, or modifying the resource.The pod security standards are policies that include properties that workloads must follow. For example, the restricted standard requires that containers set the securityContext.allowPrivilegeEscalation field to false.Pod security standards apply both to workloads, such as deployments and jobs, and to pods.When a pod is created, the admission controller inspects the container specifications and enumerates the fields that violate the pod security standard of the namespace. The admission controller inspects the pod-security labels in the namespace to decide which pod security standard to apply (restricted, baseline, or privileged), and which action to take on violations. Namespaces can audit, warn, or enforce pod security standard violations. When the pod-security.kubernetes.io/audit annotation is set to restricted, the admission controller prevents the creation of pods that violate the security standard. When the pod-security.kubernetes.io/audit and pod-security.kubernetes.io/warn annotations are defined in the project, the admission controller does not block the creation of pods, but registers audit events or warnings.The admission controller does not enforce pod security standards for workloads. If the namespace is configured to enforce a pod security standard, then you can create a violating workload. The admission controller enforces only pod security policies on pods.Cluster administrators can use pod security standards to ensure that pods and workloads in namespaces limit their privileges. By limiting privileges, cluster administrators can mitigate what malicious pods can do.The default configuration of user namespaces in OpenShift does not restrict any workload; it only notifies users when they create workloads that do not follow pod security standards that might be enforced in future OpenShift versions.Security Context ConstraintsOpenShift introduced security context constraints (SCC) before the introduction of pod security standards in Kubernetes. SCCs automatically make security modifications to pods when they are created. By default, the system:openshift:scc:restricted-v2 cluster role binding applies to all authenticated users, so regular user workloads use the restricted-v2 SCC. For example, when you execute the following command to create a workload without any security configuration, the SCC adds security configuration to the pods: [user@host ~]$ oc create deployment test --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx (You can add the --dry-run=client -o yaml options to view the deployment manifest. The deployment manifest does not contain the security properties, which are described later.)If you inspect the pods that the deployment created, the SCC makes the following changes: [user@host ~]$ oc get pod test-b8d5658b6-7bxfs -o yamlapiVersion: v1kind: Podmetadata: annotations:... output omitted... openshift.io/scc: restricted-v2 seccomp.security.alpha.kubernetes.io/pod: runtime/default...output omitted...spec: containers: - image: registry.ocp4.example.com:8443/redhattraining/hello-world-nginx imagePullPolicy: Always name: hello-world-nginx resources: {} securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true runAsUser: 1000690000... output omitted... securityContext: fsGroup: 1000690000 seLinuxOptions: level: s0:c26,c20 seccompProfile: type: RuntimeDefault... output omitted... These restrictions satisfy the restricted pod security policy.The result of these defaults means that when creating a workload (such as a deployment) in a namespace without any customization, the restricted pod security standard applies, but the admission controller only warns and audits. If the workload does not satisfy the pod security standard, then the admission controller allows the workload to be created, but prints a message such as the following warning: Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "example" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "database" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "example" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") However, by default Kubernetes creates the deployment pods with the restricted-v2 SCC, with the restrictions that the previous warning included. Due to the following factors, workloads generate only a warning, and the pod security standard admission controller allows their pods:The pod security standard admission controller never enforces pod security standards on workloads (only on pods).By default, namespaces do not enforce pod security standards on pods.By default, regular workloads create pods by using the restricted-v2 SCC, which satisfies the restricted pod security standard.Even if future versions of OpenShift change the default namespace configuration to enforce the restricted pod security standard, users will continue to be able to create workloads without explicitly declaring the restrictions that the pod security standard requires, because the restricted-v2 SCC will apply such restrictions automatically.You can take the following approaches to handling pod security:For most workloads, the restricted-v2 SCC limits pod privileges adequately. When creating a workload, you receive the warning, but the workload creates pods and works correctly.You can also create your workloads by providing a full specification of the security constraints to apply, without relying on the SCC to provide the configuration. By following this approach, privileges are more explicit, and you have greater control, so you can adjust more precisely the specific privileges that are granted to workloads.When the restricted-v2 SCC and the default restricted pod security standard are not adequate for your workload, because either you require further privileges, or you need further restrictions, you must use an existing SCC, or create a custom SCC, and provide explicit security specifications. You can also adjust the namespace labels to choose a different pod security standard, and decide to audit, log, or enforce the standard.

1473

Welcome to the Red Hat OpenShift Administration II (DO280) group in the Red Hat Learning Community!

Deanna

17 kwi 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster!To gain the most value from this group - click the "Join Group" button in the upper right hand corner.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to DO280.Read more about Red Hat OpenShift Administration II here.Thanks!

1334

Revision: do280-4.14-08d11e1