DO280 - ch06s06

Bookmark this page

Guided Exercise: The Project Template and the Self-Provisioner Role

Restrict the ability to self-provision projects to a group of users, and ensure that all users from that group have write privileges on all projects that any of them creates. Also, ensure that their new projects are constrained by a limit range that restricts memory usage.

Outcomes

Limit project creation to a group of users.
Customize project creation.

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

This command performs the following actions:

Ensure that the cluster API is reachable.
Create the provisioner1 and provisioner2 users with the redhat password.

[student@workstation ~]$ lab start selfservice-projtemplate

Instructions

In this exercise, you configure the cluster so that only members of the provisioners group can create projects. Members of the provisioners group have full permissions on new projects. Users cannot create workloads that request more than 1 GiB of RAM in new projects.

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

Allow only members of the provisioners group to create projects.
1. Examine the provisioners group.
```
[student@workstation ~]$ oc describe group provisioners
Name:           provisioners
Created:        12 seconds ago
Labels:         <none>
Annotations:    <none>
Users:          provisioner1
                provisioner2
```
  The provisioners group contains the provisioner1 and provisioner2 users.
2. Use the oc edit command to edit the self-provisioners cluster role binding.
```
[student@workstation ~]$ oc edit clusterrolebinding self-provisioners
```
  The oc edit command launches the vi editor to apply your modifications. Change the subject of the role binding from the system:authenticated:oauth group to the provisioners group.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
...output omitted...
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: self-provisioner
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: provisioners
```
  Note
  The rbac.authorization.kubernetes.io/autoupdate annotation protects this cluster role binding. If the API server restarts, then Kubernetes restores this cluster role binding.
  In this exercise context, you are not required to make the change permanent.
  Not in this exercise, but in a real-world context, you would make the change permanent by using the following command:
```
[user@host ~]$ oc annotate clusterrolebinding/self-provisioners \
  --overwrite rbac.authorization.kubernetes.io/autoupdate=false
```
Verify that users outside the provisioners group cannot create projects.
1. Log in to the cluster as the developer user with the developer password.
```
[student@workstation ~]$ oc login -u developer -p developer
Login successful.

You don't have any projects. Contact your system administrator to request a project.
```
  After the role binding is changed, the oc login command reports that you must contact your system administrator to request a project, because the developer user cannot create projects.
2. Verify that the developer user cannot create projects.
```
[student@workstation ~]$ oc new-project test
Error from server (Forbidden): You may not request a new project via this API.
```

Verify that members of the provisioners group can create projects.

[student@workstation ~]$ oc login -u provisioner1 -p redhat
Login successful.

You don't have any projects. You can try to create a new project, by running
...output omitted...

Create a project by using the oc new-project command.

[student@workstation ~]$ oc new-project test
Now using project "test" on server "https://api.ocp4.example.com:6443".
...output omitted...

Verify that you can create resources in the test project.

[student@workstation ~]$ oc create configmap test
configmap/test created

Verify that another member of the provisioners group cannot access the test project.

[student@workstation ~]$ oc login -u provisioner2 -p redhat
Login successful.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

The oc login command reports that the provisioner2 user does not have any projects.

Try to change to the test project with the oc project command.

[student@workstation ~]$ oc project test
error: You are not a member of project "test".
You are not a member of any projects. You can request a project to be created with the 'new-project' command.

[student@workstation ~]$ oc login -u admin -p redhatocp
...output omitted...

Delete the test project.

[student@workstation ~]$ oc delete project test
project.project.openshift.io "test" deleted

Create a namespace to design a project template. Add a limit range that prevents users from creating workloads that request more than 1 GiB of RAM.

Use the oc create namespace command to create the template-test namespace.

[student@workstation ~]$ oc create namespace template-test
namespace/template-test created

Edit the ~/DO280/labs/selfservice-projtemplate/limitrange.yaml file to add the limit. The file must match the following content:

apiVersion: v1
kind: LimitRange
metadata:
  name: max-memory
  namespace: template-test
spec:
  limits:
  - max:
      memory: 1Gi
    type: Container

Use the oc create command to create the limit range that the ~/DO280/labs/selfservice-projtemplate/limitrange.yaml file defines.

[student@workstation ~]$ oc create \
  -f ~/DO280/labs/selfservice-projtemplate/limitrange.yaml
limitrange/max-memory created

Examine the ~/DO280/labs/selfservice-projtemplate/deployment.yaml file. This file defines a deployment that requests 2 GiB of RAM.

apiVersion: apps/v1
kind: Deployment
metadata:
...output omitted...
  name: test
spec:
...output omitted...
  template:
...output omitted...
    spec:
      containers:
      - image: registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0
        name: hello-world-nginx
        resources:
          limits:
            memory: 2Gi

Create the deployment by using the ~/DO280/labs/selfservice-projtemplate/deployment.yaml file.

[student@workstation ~]$ oc create \
  -f ~/DO280/labs/selfservice-projtemplate/deployment.yaml \
  -n template-test
deployment.apps/test created

Examine the pods and events in the template-test namespace.

[student@workstation ~]$ oc get pod -n template-test
No resources found in template-test namespace.

[student@workstation ~]$ oc get event -n template-test \
  --sort-by=metadata.creationTimestamp
LAST SEEN   TYPE      REASON              OBJECT                       MESSAGE
...output omitted...
39s         Warning   FailedCreate        replicaset/test-846769884c   Error creating: pods "test-846769884c-5zjhw" is forbidden: maximum memory usage per Container is 1Gi, but limit is 2Gi

The limit range maximum prevents the deployment from creating pods.

Define the project template.
The ~/DO280/solutions/selfservice-projtemplate/template.yaml file contains a solution.
1. Use the oc adm create-bootstrap-project-template command to print an initial project template. Redirect the output to the template.yaml file.
```
[student@workstation ~]$ oc adm create-bootstrap-project-template \
  -o yaml >template.yaml
```
2. Use the oc command to list the limit range in YAML format. Redirect the output to append to the template.yaml file.
```
[student@workstation ~]$ oc get limitrange -n template-test \
  -o yaml >>template.yaml
```
3. Edit the template.yaml file to perform the following operations:
  - Apply the following changes to the subjects key in the admin role binding:
    Change the kind key to Group.
    Change the name key to provisioners.
  - Move the limit range to immediately after the role binding definition.
  - Replace the namespace: template-test text with the namespace: ${PROJECT_NAME} text.
  - Remove any left-over content after the parameters block.
  - Remove the following keys from the limit range and quota definitions:
    creationTimestamp
    resourceVersion
    uid
  If you use the vi editor, then you can use the following procedure to move a block of text:
  - Move to the beginning of the block.
  - Press V to enter visual line mode. This mode selects entire lines for manipulation.
  - Move to the end of the block. The editor highlights the selected lines.
  - Press d to delete the lines and to store them in a register for later use.
  - Move to the destination.
  - Press P to insert the lines that are stored in the register.
  You can also press dd to delete entire lines, and press . to repeat the operation.
  The resulting file should match the following content:
```
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  creationTimestamp: null
  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}
    creationTimestamp: null
    name: ${PROJECT_NAME}
  spec: {}
  status: {}
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: null
    name: admin
    namespace: ${PROJECT_NAME}
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: provisioners
- apiVersion: v1
  kind: LimitRange
  metadata:
    name: max-memory
    namespace: ${PROJECT_NAME}
  spec:
    limits:
    - default:
        memory: 1Gi
      defaultRequest:
        memory: 1Gi
      max:
        memory: 1Gi
      type: Container
parameters:
- name: PROJECT_NAME
- name: PROJECT_DISPLAYNAME
- name: PROJECT_DESCRIPTION
- name: PROJECT_ADMIN_USER
- name: PROJECT_REQUESTING_USER
```
  Note
  The limit range has default and defaultRequest limits, although the definition does not contain these keys. When creating a limit range, always set the default and defaultRequest limits for more predictable behavior.

Create and configure the project template.

Use the oc command to create the project template.

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

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

[student@workstation ~]$ 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

Use the watch command to view the API server pods.

[student@workstation ~]$ watch oc get pod -n openshift-apiserver
NAME		    READY   STATUS    RESTARTS	  AGE
apiserver-6b7b...   2/2	    Running   0           2m30s

Wait until new pods are rolled out. The rollout can take a few minutes to start. Press Ctrl+C to exit the watch command.

Create a project as the provisioner1 user.

[student@workstation ~]$ oc login -u provisioner1 -p redhat
Login successful.
...output omitted...

Create a project by using the oc new-project command.

[student@workstation ~]$ oc new-project test
Now using project "test" on server "https://api.ocp4.example.com:6443".
...output omitted...

Verify that the provisioner2 user can access the test project and create resources. Verify that the limit range has the intended effect.

Log in to the cluster as the provisioner2 user with the redhat password.
```
[student@workstation ~]$ oc login -u provisioner2 -p redhat
Login successful.

You have one project on this server: "test"

Using project "test".
```
The oc login command reports that the provisioner2 user has the test project. The command selects the project.
Create a resource on the test project.
```
[student@workstation ~]$ oc create configmap test
configmap/test created
```
The provisioner2 user can create resources in a project that the provisioner1 user created.

Create a deployment that exceeds the limit range by using the ~/DO280/labs/selfservice-projtemplate/deployment.yaml file.

[student@workstation ~]$ oc create \
  -f ~/DO280/labs/selfservice-projtemplate/deployment.yaml
deployment.apps/test created

Examine the pods and events in the template-test namespace.

[student@workstation ~]$ oc get pod
No resources found in test namespace.

[student@workstation ~]$ oc get event --sort-by=metadata.creationTimestamp
LAST SEEN   TYPE      REASON              OBJECT                       MESSAGE
...output omitted...
39s         Warning   FailedCreate        replicaset/test-846769884c   Error creating: pods "test-846769884c-5zjhw" is forbidden: maximum memory usage per Container is 1Gi, but limit is 2Gi

The limit range works as expected.

Finish

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 selfservice-projtemplate

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

Red Hat OpenShift Administration II: Configuring a Production Cluster

Guided Exercise: The Project Template and the Self-Provisioner Role

Note

Note