DO280 - ch08s07

Bookmark this page

Lab: Application Security

Deploy an application that requires additional operating system privileges to run.

Deploy an application that requires access to the Kubernetes APIs to perform cluster maintenance tasks.

Outcomes

Deploy a cluster maintenance application that must be executed regularly.
Grant application access to Kubernetes APIs.
Run an application with a security context constraint (SCC).

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

[student@workstation ~]$ lab start appsec-review

In this exercise, you deploy two applications:

A legacy payroll application that must run as the fixed 0 UID to open the TCP 80 port.
A project cleaner deletes projects with the appsec-review-cleaner label and that are longer than 10 seconds. This short expiration time is deliberate for the lab purposes.

You must deploy the project cleaner application to delete obsolete projects every minute.

The lab start command copies the required files for the exercise to the lab directory:

A deployment manifest with the payroll application.
A pod manifest that contains a project cleaner application. You can use this pod to test the project cleaner application and copy the pod specification into the cron job to complete the exercise.
A manifest with the project-cleaner cluster role that grants the application access to find and delete namespaces.
A cron job template file that you can edit to create cron jobs.
A script that generates projects to verify that the project cleaner application works.

Instructions

Log in to your OpenShift cluster as the developer user with the developer password and create the appsec-review project.

[student@workstation ~]$ oc login -u developer -p developer \
  https://api.ocp4.example.com:6443
Login successful.

...output omitted...

Create the appsec-review project.

[student@workstation ~]$ oc new-project appsec-review
Now using project "appsec-review" on server ...
...output omitted...

Change to the ~/DO280/labs/appsec-review directory and deploy the payroll application in the payroll-app.yaml file. Verify that the application cannot run.

Change to the ~/DO280/labs/appsec-review directory to access the lab files.
```
[student@workstation ~]$ cd ~/DO280/labs/appsec-review
```

Run the oc apply command to create the payroll deployment.

[student@workstation appsec-review]$ oc apply -f payroll-app.yaml
deployment.apps/payroll-api created

Verify that the application fails to run by reading the deployment logs.

[student@workstation appsec-review]$ oc logs deployment/payroll-api
[2023-03-13 08:13:30 +0000] [1] [INFO] Starting gunicorn 20.1.0
[2023-03-13 08:13:30 +0000] [1] [ERROR] Retrying in 1 second.
[2023-03-13 08:13:31 +0000] [1] [ERROR] Retrying in 1 second.
[2023-03-13 08:13:32 +0000] [1] [ERROR] Retrying in 1 second.
[2023-03-13 08:13:33 +0000] [1] [ERROR] Retrying in 1 second.
[2023-03-13 08:13:34 +0000] [1] [ERROR] Retrying in 1 second.
[2023-03-13 08:13:35 +0000] [1] [ERROR] Can't connect to ('', 80)

The container in the pod runs as root to listen on port 80.

As the admin user, look for an SCC that allows the workload in the payroll-app.yaml deployment to run.

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

Run the oc adm policy scc-subject-review command to get an SCC that allows the application to run.

[student@workstation appsec-review]$ oc adm policy scc-subject-review \
  -f payroll-app.yaml
RESOURCE                 ALLOWED BY
Deployment/payroll-api   anyuid

Create the payroll-sa service account and assign to it the SCC that the application requires. Then, assign the payroll-sa service account to the payroll-api deployment.

Run the oc create command to create the payroll-sa service account.

[student@workstation appsec-review]$ oc create sa payroll-sa
serviceaccount/payroll-sa created

Assign the anyuid SCC to the payroll-sa service account.

[student@workstation appsec-review]$ oc adm policy \
  add-scc-to-user anyuid -z payroll-sa
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "payroll-sa"

Use the oc set serviceaccount command to add the payroll-sa service account to the payroll-api deployment.

[student@workstation appsec-review]$ oc set serviceaccount deployment \
  payroll-api payroll-sa
deployment.apps/payroll-api serviceaccount updated

Verify that the payroll API is accessible by running the curl command from the payroll-api deployment. Use the http://localhost/payments/status URL to verify that the API is working.
Use the oc exec command with the payroll-api deployment to run the curl command. Provide the -sS option to hide progress output and show errors.
[student@workstation appsec-review]$ oc exec deployment/payroll-api \ -- curl -sS http://localhost/payments/status [{"id":240,"status":"Paid","userId":1003},{"id":241,"status":"Pending","userId":1003}]

Create the project-cleaner-sa service account and assign it to the project-cleaner.yaml pod manifest to configure the application permissions.

Create the project-cleaner-sa service account.

[student@workstation appsec-review]$ oc create sa project-cleaner-sa
serviceaccount/project-cleaner-sa created

Edit the project-cleaner.yaml pod manifest file to use the project-cleaner-sa service account.

apiVersion: v1
kind: Pod
metadata:
  name: project-cleaner
  namespace: appsec-review
spec:
  restartPolicy: Never
  serviceAccountName: project-cleaner-sa
  containers:
    - name: project-cleaner
...output omitted...

Create the project-cleaner role in the cluster-role.yaml file and assign it to the project-cleaner-sa service account.

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

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

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

[student@workstation appsec-review]$ 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"

Edit the cron-job.yaml file to create the appsec-review-cleaner cron job by using the project-cleaner.yaml pod manifest as the job template. Create the cron job and configure it to run every minute. You can use the solution file in the ~/DO280/solutions/appsec-review/cron-job.yaml path.

Edit the cron-job.yaml file to replace the CHANGE_ME string with the "*/1 * * * *" schedule to execute the job every minute.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: appsec-review-cleaner
  namespace: appsec-review
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
  ...output omitted...

Replace the CHANGE_ME label in the jobTemplate definition with the spec definition from the project-cleaner.yaml pod manifest. Although the long image name might show across two lines, you must add it as one line.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: appsec-review-cleaner
  namespace: appsec-review
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: "appsec-review-cleaner"
              - name: "EXPIRATION_SECONDS"
                value: "10"

Create the cron job.

[student@workstation appsec-review]$ oc apply -f cron-job.yaml
cronjob.batch/appsec-review-cleaner created

Optionally, verify that the project cleaner executed correctly. Use the generate-projects.sh script from the lab directory to generate projects for deletion. Wait for the next job execution and print the logs from that job's pod.

Run the generate-projects.sh script to create test projects that the project cleaner will delete the next time that it runs.

[student@workstation appsec-review]$ ./generate-projects.sh
obsolete-appsec-review-1 created at 15:29:14
obsolete-appsec-review-2 created at 15:29:15
obsolete-appsec-review-3 created at 15:29:16
namespace/obsolete-appsec-review-1 labeled
namespace/obsolete-appsec-review-2 labeled
namespace/obsolete-appsec-review-3 labeled
Last appsec-review-cleaner label applied at 15:29:20
...output omitted...

List the pods in the appsec-review project until you see a pod with the Completed status that is later than the last label that the script applied.

[student@workstation appsec-review]$ oc get pods
NAME                                READY   STATUS      RESTARTS   AGE
appsec-review-cleaner-27909204-g49gr   0/1     Completed   0          2m37s
appsec-review-cleaner-27909205-q2f2t   0/1     Completed   0          97s
appsec-review-cleaner-27909206-xcswb   0/1     Completed   0          37s

Print the logs from the last completed job, to verify that it deleted the obsolete projects.

[student@workstation appsec-review]$ oc logs pod/appsec-review-cleaner-27909206-xcswb
...output omitted...
Namespace 'obsolete-appsec-review-1' deleted
Namespace 'obsolete-appsec-review-2' deleted
Namespace 'obsolete-appsec-review-3' deleted

Change to the home directory to prepare for the next exercise.
```
[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 appsec-review

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 appsec-review

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