DO280 - ch10s02

Bookmark this page

Lab: Cluster Self-service Setup

Configure a cluster with default settings for self-service projects.

Outcomes

Create a project template that sets quotas, ranges, and network policies.
Restrict access to the self-provisioners cluster role.
Create groups and assign users to groups.
Use role-based access control (RBAC) to grant permissions to groups.

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

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

The lab command copies the exercise files to the ~/DO280 directory and creates the following users:

do280-support
do280-platform
do280-presenter
do280-attendee

The goal, as the cluster administrator, is to configure a dedicated cluster to host workshops on different topics.

Each workshop requires a project, so that workshops are isolated from each other.

You must set up the cluster so that when the presenter creates a workshop project, the project gets a base configuration.

The presenter must be mostly self-sufficient to administer a workshop with little help from the workshop support team.

The workshop support team must deploy applications that administer workshops and that enhance the workshop experience. You set up a project and the applications for this purpose on a second lab.

Specifications

Use the following values to access the OpenShift cluster:

Item	Value
`Dev user/password`	`developer/developer`
`Admin user/password`	`admin/redhatocp`
`API URL`	`https://api.ocp4.example.com:6443`

The following workshop groups are required:

Create the groups with the specified users in the following table:
Group User
platform do280-platform
presenters do280-presenter
workshop-support do280-support
The lab start command creates the users with the redhat password.
The platform group administers the cluster.
The presenters group consists of the people who deliver the workshops.
The workshop-support group maintains the needed applications to support the workshops and the workshop presenters.
Ensure that only users from the following groups can create projects:
Group
platform
presenters
workshop-support
An attendee must not be able to create projects. Because this exercise requires steps that restart the Kubernetes API server, this configuration must persist across API server restarts.
The workshop-support group requires the following roles in the cluster:
- The admin role to administer projects
- A custom role that is provided in the groups-role.yaml file You must create this custom role to enable support members to create workshop groups and to add workshop attendees.
The platform group must be able to administer the cluster without restrictions.
The workshop-support group must perform the following tasks for the workshop project:
- Create a workshop-specific attendees group.
- Assign the edit role to the attendees group.
- Add users to the attendees group.
Each workshop must be hosted in an independent project.
All the resources that the cluster creates with a new workshop project must use workshop as the name for grading purposes.
Each workshop must enforce the following maximum constraints:
- The project uses up to 2 CPUs.
- The project uses up to 1 Gi of RAM.
- The project requests up to 1.5 CPUs.
- The project requests up to 750 Mi of RAM.
Each workshop must enforce constraints to prevent an attendee's workload from consuming all the allocated resources for the workshop:
- A workload uses up to 750m CPUs.
- A workload uses up to 750 Mi.
Each workshop must have a resource specification for workloads:
- A default limit of 500m CPUs.
- A default limit of 500 Mi of RAM.
- A default request of 0.1 CPUs.
- A default request of 250 Mi of RAM.
  You can use the templates that are provided in the quota.yaml, limitrange.yaml, and networkpolicy.yaml files.
Each workshop project must have this additional default configuration:
- A local binding for the presenter user to the admin cluster role with the workshop name
- The workshop=project_name label to help to identify the workshop workload
- Must accept traffic only from within the same workshop or from the ingress controller.
Use the registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0 image, which listens on the 8080 port, to simulate a workshop workload.
As the do280-presenter user, you must create a workshop with the do280 name.
As the do280-support user, you must create the do280-attendees group with the do280-attendee user, and assign the edit cluster role to the do280-attendees group.

Group	User
`platform`	`do280-platform`
`presenters`	`do280-presenter`
`workshop-support`	`do280-support`

Group
`platform`
`presenters`
`workshop-support`

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

Change to the lab directory.

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

Open a terminal window and log in as the admin user with the redhatocp password.

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

Create the following groups and add a user as specified in the following table.

Group	User
`workshop-support`	`do280-support`
`presenters`	`do280-presenter`
`platform`	`do280-platform`

Create the workshop-support group.

[student@workstation compreview-review]$ oc adm groups new workshop-support
group.user.openshift.io/workshop-support created

Add the do280-support user to the workshop-support group.

[student@workstation compreview-review]$ oc adm groups add-users \
  workshop-support do280-support
group.user.openshift.io/workshop-support added: "do280-support"

Create the presenters group.

[student@workstation compreview-review]$ oc adm groups new presenters
group.user.openshift.io/presenters created

Add the do280-presenter user to the presenters group.

[student@workstation compreview-review]$ oc adm groups add-users \
  presenters do280-presenter
group.user.openshift.io/presenters added: "do280-presenter"

Create the platform group.

[student@workstation compreview-review]$ oc adm groups new platform
group.user.openshift.io/platform created

Add the do280-platform user to the platform group.

[student@workstation compreview-review]$ oc adm groups add-users \
  platform do280-platform
group.user.openshift.io/platform added: "do280-platform"

Use the oc get groups command to verify that the group configuration is correct.

[student@workstation compreview-review]$ oc get groups
NAME                               USERS
...output omitted...
platform                           do280-platform
presenters                         do280-presenter
workshop-support                   do280-support

Grant to the workshop-support group the admin and the custom manage-groups cluster roles. You must create the manage-groups custom cluster role from the groups⁠-⁠role⁠.⁠yaml file.

Grant the admin cluster role to the workshop-support group.

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

Run the oc create command to create the manage-groups cluster role in the groups-role.yaml file.

[student@workstation compreview-review]$ oc create -f groups-role.yaml
clusterrole.rbac.authorization.k8s.io/manage-groups created

Grant the manage-groups cluster role to the workshop-support group.

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

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

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

Allow only the platform, workshop-support and presenters groups to create projects, by editing the self-provisioner cluster role. Enforce that only users from these groups can create projects. Also, make this change permanent by setting the rbac.authorization.kubernetes.io/autoupdate annotation with the false value.

Use the oc edit command to edit the self-provisioners cluster role binding.

[student@workstation compreview-review]$ oc edit clusterrolebinding \
  self-provisioners

Replace the subject of the role binding for the system:authenticated:oauth group with the platform, workshop-support, and presenters groups.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "false"
  creationTimestamp: "2023-01-24T23:31:00Z"
  name: self-provisioners
  resourceVersion: "250330"
  uid: a6053896-f68f-41ff-9bb3-5da579a701bc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: self-provisioner
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: platform
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: workshop-support
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: presenters

As the do280-attendee user, verify that you cannot create a project.

[student@workstation compreview-review]$ oc login -u do280-attendee -p redhat
Login successful.

You don't have any projects. Contact your system administrator to request a project.

Use the oc new-project command to try to create a template-test project.

[student@workstation compreview-review]$ oc new-project template-test
Error from server (Forbidden): You may not request a new project via this API.

As the admin user, create a template-test namespace to design the project template.

[student@workstation compreview-review]$ oc login -u admin -p redhatocp
Login successful.
...output omitted...

Use the oc new-project command to create the template-test project.

[student@workstation compreview-review]$ oc new-project template-test
Now using project "template-test" on server...
...output omitted...

Create a template resource quota with the following specification.
Quota Value
limits.cpu 2
limits.memory 1Gi
requests.cpu 1500m
requests.memory 750Mi
1. Edit the quota.yaml file and replace the CHANGE_ME label to match the following definition.
```
apiVersion: v1
kind: ResourceQuota
metadata:
 name: workshop
 namespace: template-test
spec:
  hard:
    limits.cpu: 2
    limits.memory: 1Gi
    requests.cpu: 1500m
    requests.memory: 750Mi
```
2. Use the oc create command to create the quota in the template-test project.
```
[student@workstation compreview-review]$ oc create -f quota.yaml
resourcequota/workshop created
```

Quota	Value
`limits.cpu`	`2`
`limits.memory`	`1Gi`
`requests.cpu`	`1500m`
`requests.memory`	`750Mi`

Create the workshop limit range with the following specification.

Limit type	Value
`max.cpu`	`750m`
`max.mem`	`750Mi`
`default.cpu`	`500m`
`default.memory`	`500Mi`
`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
 namespace: template-test
spec:
 limits:
   - max:
       cpu: 750m
       memory: 750Mi
     default:
       cpu: 500m
       memory: 500Mi
     defaultRequest:
       cpu: 100m
       memory: 250Mi
     type: Container

Use the oc create command to create the limit range in the template-test project.

[student@workstation compreview-review]$ oc create -f limitrange.yaml
limitrange/workshop created

Create a network policy to accept traffic from within the workshop project or from outside the cluster. To identify the workshop project traffic, label the template-test namespace with the workshop=template-test label.

Use the oc create deployment command to create a deployment without resource specifications.

[student@workstation compreview-review]$ oc create deployment test-workload \
  --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0
deployment.apps/test-workload created

Get the IP address of one of the NGINX pods.

[student@workstation compreview-review]$ oc get pod -o wide
NAME                                 READY   STATUS    ...   IP     ...
test-workload-56bf7dc6fc-mshn9   1/1     Running   ... 10.8.0.138  ...

Use the oc debug command to run the curl command from a pod in the default project.

Use the curl command from the default namespace to query the NGINX server that runs in the test workload.

[student@workstation compreview-review]$ oc debug --to-namespace="default" \
  -- curl -s http://10.8.0.138:8080
Starting pod/image-debug ...
<html>
  <body>
    <h1>Hello, world from nginx!</h1>
  </body>
</html>

Removing debug pod ...

Use the oc label command to add the label to the template-test namespace.

[student@workstation compreview-review]$ oc label ns template-test \
  workshop=template-test
namespace/template-test labeled

Edit the network policy from the networkpolicy.yaml file. Replace the CHANGE_ME labels according to the following specification.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: workshop
  namespace: template-test
spec:
  podSelector: {}
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            workshop: template-test
      - namespaceSelector:
          matchLabels:
            policy-group.network.openshift.io/ingress: ""

Run the oc create command to create the policy in the template-test project.

[student@workstation compreview-review]$ oc create -f networkpolicy.yaml
networkpolicy.networking.k8s.io/workshop created

Verify that you cannot connect to the workshop pod from the default project.

[student@workstation compreview-review]$ oc debug --to-namespace="default" \
  -- curl -sS --connect-timeout 5 http://10.8.0.138:8080
Starting pod/image-debug ...
curl: (28) Connection timed out after 5000 milliseconds

Removing debug pod ...

Verify that you can connect to the workshop pod from the workshop project.

[student@workstation compreview-review]$ oc debug \
  --to-namespace="template-test" \
  -- curl -sS http://10.8.0.138:8080
Warning: would violate PodSecurity "restricted:latest": ...output omitted...
Starting pod/image-debug ...
<html>
  <body>
    <h1>Hello, world from nginx!</h1>
  </body>
</html>

Removing debug pod ...

Create the workshop project template by using the previously created template resources.

Run the oc adm create-bootstrap-project-template command to create the project-template.yaml file to use as the template for new projects.
```
[student@workstation compreview-review]$ oc adm \
  create-bootstrap-project-template \
  -o yaml > project-template.yaml
```
Use the oc get command to create a YAML list with the following resources:
- resourcequota/workshop
- limitrange/workshop
- networkpolicy/workshop
  Redirect the output to append to the project-template.yaml file.
```
[student@workstation compreview-review]$ oc get resourcequota/workshop \
  limitrange/workshop \
  networkpolicy/workshop \
  -o yaml >> project-template.yaml
```

Edit the project-template.yaml file to perform the following operations:

Cut the contents of the items stanza and paste them immediately before the parameters stanza. Keep the original indentation, because every YAML item of the list must appear at the beginning of the line.
Remove any left-over content after the parameters block.
Remove the following keys from the limit range and quota definitions:
- creationTimestamp
- resourceVersion
- uid
- status
- generation
Replace the template-test text with the ${PROJECT_NAME} text.
Add the workshop=${PROJECT_NAME} label.
Rename the admin role binding with the workshop name.

Use the search-and-replace editor function to replace the template-test string with the ${PROJECT_NAME} template parameter. Optionally, you can use the sed command if it is available.

The solution file is in the ~/DO280/solutions/compreview-review/project-template.yaml path.

[student@workstation compreview-review]$ sed -i \
  's/template-test/${PROJECT_NAME}/g' project-template.yaml

Then, move the resource list to the objects key. The project-template.yaml file has the following expected content.

apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: project-request
objects:
- apiVersion: project.openshift.io/v1
  kind: Project
  metadata:
    annotations:
      openshift.io/description: ${PROJECT_DESCRIPTION}
      openshift.io/display-name: ${PROJECT_DISPLAYNAME}
      openshift.io/requester: ${PROJECT_REQUESTING_USER}
    name: ${PROJECT_NAME}
    labels:
      workshop: ${PROJECT_NAME}
  spec: {}
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: workshop
    namespace: ${PROJECT_NAME}
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: ${PROJECT_ADMIN_USER}
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    annotations:
    name: workshop
    namespace: ${PROJECT_NAME}
  spec:
    hard:
      limits.cpu: "2"
      limits.memory: 1Gi
      requests.cpu: 1500m
      requests.memory: 750Mi
- apiVersion: v1
  kind: LimitRange
  metadata:
    annotations:
    name: workshop
    namespace: ${PROJECT_NAME}
  spec:
    limits:
    - default:
        cpu: 500m
        memory: 500Mi
      defaultRequest:
        cpu: 100m
        memory: 250Mi
      max:
        cpu: 750m
        memory: 750Mi
      type: Container
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    annotations:
    name: workshop
    namespace: ${PROJECT_NAME}
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            workshop: ${PROJECT_NAME}
      - namespaceSelector:
          matchLabels:
            policy-group.network.openshift.io/ingress: ""
    podSelector: {}
    policyTypes:
    - Ingress
parameters:
- name: PROJECT_NAME
- name: PROJECT_DISPLAYNAME
- name: PROJECT_DESCRIPTION
- name: PROJECT_ADMIN_USER
- name: PROJECT_REQUESTING_USER

Create the project template in the project-template.yaml file by using the oc create command in the openshift-config namespace.

[student@workstation compreview-review]$ oc create -f project-template.yaml \
  -n openshift-config
template.template.openshift.io/project-request created

Use the oc edit command to change the cluster project configuration.

[student@workstation compreview-review]$ oc edit \
  projects.config.openshift.io cluster

Edit the resource to match the following content:

apiVersion: config.openshift.io/v1
kind: Project
metadata:
...output omitted...
  name: cluster
...output omitted...
spec:
  projectRequestTemplate:
    name: project-request

To edit the file, you use the default vi editor.

Use the watch command to view the API server pods.
```
[student@workstation compreview-review]$ watch oc get \
  pod -n openshift-apiserver
```
Wait until new pods are created. Press Ctrl+C to exit the watch command.

As the do280-presenter, create the do280 workshop project.

[student@workstation compreview-review]$ oc login -u do280-presenter -p redhat
Login successful.
...output omitted...

Use the oc new-project command to create the do280 project.

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

Verify that the oc new-project command creates the following resources from the template:

Quota
Limit range

Network policy

[student@workstation compreview-review]$ oc get resourcequota/workshop \
  limitrange/workshop \
  networkpolicy/workshop
NAME                     AGE   REQUEST                   LIMIT
resourcequota/workshop   95s   requests.cpu: 0/1500m ... limits.cpu: 0/2 ...
NAME                  CREATED AT
limitrange/workshop   2023-03-03T10:37:28Z
NAME                                       POD-SELECTOR   AGE
networkpolicy.networking.k8s.io/workshop   <none>         95s

Verify that the do280 project definition has the workshop=do280 label.

[student@workstation compreview-review]$ oc get project do280 -o yaml
apiVersion: project.openshift.io/v1
kind: Project
metadata:
...output omitted...
  labels:
    workshop: do280
...output omitted...
  name: do280
  resourceVersion: "1293438"
...output omitted...

As the do280-support user, create the do280-attendees group. Then, assign the edit cluster role to the do280-attendees group, and add the do280-attendee user to the group.

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

Create the do280-attendees group.

[student@workstation compreview-review]$ oc adm groups new do280-attendees
group.user.openshift.io/do280-attendees created

Assign the edit role to the do280-attendees group in the do280-workshop project.

Add the edit cluster role to the do280-attendees group in the do280 project.

[student@workstation compreview-review]$ oc adm policy \
  add-role-to-group edit do280-attendees -n do280
clusterrole.rbac.authorization.k8s.io/edit added: "do280-attendees"

As the do280-attendee user, verify that you cannot access the do280 project.

[student@workstation compreview-review]$ oc login -u do280-attendee -p redhat
Login successful.
You don't have any projects. ...

As the do280-support user, add the do280-attendee user to the do280-attendees group.

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

Use the oc adm groups command to add the do280-attendee user to the workshop-do280-attendees group.

[student@workstation compreview-review]$ oc adm groups add-users \
  do280-attendees do280-attendee
group.user.openshift.io/do280-attendees added: "do280-attendee"

As the do280-attendee user, verify that you can create workloads in the do280 project.

[student@workstation compreview-review]$ oc login -u do280-attendee -p redhat
Login successful.
You have one project on this server: "do280"
Using project "do280".

Use the oc create deployment command to create a deployment without resource specifications.

[student@workstation compreview-review]$ oc create deployment \
  attendee-workload \
  --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0
deployment.apps/attendee-workload created

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 compreview-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 compreview-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