DO280 - ch04s04

Bookmark this page

Guided Exercise: Configure Network Policies

Create network policies and review pod isolation that these network policies created.

Outcomes

Create network policies to control communication between pods.
Verify that ingress traffic is limited to pods.

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

This command ensures that the environment is ready and downloads the necessary resource files for the exercise.

[student@workstation ~]$ lab start network-policy

Instructions

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

...output omitted...

Create the network-policy project.

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

...output omitted...

Create two identical deployments named hello and test. Create a route to the hello deployment.

Create the hello deployment that uses the registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0 container image.

[student@workstation ~]$ oc new-app --name hello \
    --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0
...output omitted...
--> Creating resources ...
    imagestream.image.openshift.io "hello" created
    deployment.apps "hello" created
    service "hello" created
--> Success
...output omitted...

Create the test deployment that uses the registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0 container image.

[student@workstation ~]$ oc new-app --name test \
    --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0
...output omitted...
--> Creating resources ...
    imagestream.image.openshift.io "test" created
    deployment.apps "test" created
    service "test" created
--> Success
...output omitted...

Use the oc expose command to create a route to the hello service.

[student@workstation ~]$ oc expose service hello
route.route.openshift.io/hello exposed

Verify that the test pod can access the hello pod by using the oc rsh and curl commands.

Open a second terminal and run the script at ~/DO280/labs/network-policy/display-project-info.sh. This script provides information about the pods, service, and route that are used in the rest of this exercise.

[student@workstation ~]$ ~/DO280/labs/network-policy/display-project-info.sh
===================================================================
PROJECT: network-policy

POD NAME                 IP ADDRESS
hello-6c4984d949-g28c4   10.8.0.13
test-c4d74c9d5-5pq9s     10.8.0.14

SERVICE NAME   CLUSTER-IP
hello          172.30.137.226
test           172.30.159.119

ROUTE NAME   HOSTNAME                                     PORT
hello        hello-network-policy.apps.ocp4.example.com   8080-tcp
===================================================================

Access the hello pod IP address from the test pod by using the oc rsh and curl commands.

[student@workstation ~]$ oc rsh test-c4d74c9d5-5pq9s \
    curl 10.8.0.13:8080 | grep Hello
    <h1>Hello, world from nginx!</h1>

Access the hello service IP address from the test pod by using the oc rsh and curl commands.

[student@workstation ~]$ oc rsh test-c4d74c9d5-5pq9s \
    curl 172.30.137.226:8080 | grep Hello
    <h1>Hello, world from nginx!</h1>

Access the hello route hostname by using the curl command.

[student@workstation ~]$ curl -s hello-network-policy.apps.ocp4.example.com | \
    grep Hello
    <h1>Hello, world from nginx!</h1>

Create a project named different-namespace that contains a deployment named sample-app.

Create the different-namespace project.

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

Create the sample-app deployment from the registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0 image. The web app listens on port 8080.

[student@workstation ~]$ oc new-app --name sample-app \
    --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:v1.0
...output omitted...
--> Creating resources ...
    imagestream.image.openshift.io "sample-app" created
    deployment.apps "sample-app" created
    service "sample-app" created
--> Success
...output omitted...

Access the hello and test pods in the network-policy project from the sample-app pod in the different-namespace project.

In the second terminal, view the full name of the sample-app pod with the display-project-info.sh script.

[student@workstation ~]$ ~/DO280/labs/network-policy/display-project-info.sh
===================================================================
PROJECT: network-policy

POD NAME                 IP ADDRESS
hello-6c4984d949-g28c4   10.8.0.13
test-c4d74c9d5-5pq9s     10.8.0.14

SERVICE NAME   CLUSTER-IP
hello          172.30.137.226
test           172.30.159.119

ROUTE NAME   HOSTNAME                                     PORT
hello        hello-network-policy.apps.ocp4.example.com   8080-tcp
===================================================================
PROJECT: different-namespace

POD NAME
sample-app-d5f945-spx9q
===================================================================

In the first terminal, access the hello pod IP address from the sample-app pod by using the oc rsh and curl commands.

[student@workstation ~]$ oc rsh sample-app-d5f945-spx9q \
    curl 10.8.0.13:8080 | grep Hello
    <h1>Hello, world from nginx!</h1>

Access the test pod IP address from the sample-app pod by using the oc rsh and curl commands. Target the IP address that was previously retrieved for the test pod.
```
[student@workstation ~]$ oc rsh sample-app-d5f945-spx9q \
    curl 10.8.0.14:8080 | grep Hello
    <h1>Hello, world from nginx!</h1>
```

In the network-policy project, create a deny-all network policy by using the resource file at ~/DO280/labs/network-policy/deny-all.yaml.
1. Switch to the network-policy project.
```
[student@workstation ~]$ oc project network-policy
Now using project "network-policy" on server "https://api.ocp4.example.com:6443".
```
2. Change to the ~/DO280/labs/network-policy directory.
```
[student@workstation ~]$ cd ~/DO280/labs/network-policy
```
3. Use a text editor to update the deny-all.yaml file with an empty podSelector field to target all pods in the network-policy project.
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-all
spec:
  podSelector: {}
```
  Note
  A solution is provided at ~/DO280/solutions/network-policy/deny-all.yaml.
4. Create the network policy with the oc create command.
```
[student@workstation network-policy]$ oc create -f deny-all.yaml
networkpolicy.networking.k8s.io/deny-all created
```

Verify that the deny-all network policy forbids network access to pods in the network-policy project.

Verify that the test pod can no longer access the IP address of the hello pod. Wait a few seconds, and then press Ctrl+C to exit the curl command that does not reply.
```
[student@workstation network-policy]$ oc rsh test-c4d74c9d5-5pq9s \
    curl 10.8.0.13:8080 | grep Hello
^C
command terminated with exit code 130
```

Switch to the different-namespace project.

[student@workstation network-policy]$ oc project different-namespace
Now using project "different-namespace" on server "https://api.ocp4.example.com:6443".

Verify that the sample-app pod can no longer access the IP address of the test pod. Wait a few seconds, and then press Ctrl+C to exit the curl command that does not reply.
```
[student@workstation network-policy]$ oc rsh sample-app-d5f945-spx9q \
    curl 10.8.0.14:8080 | grep Hello
^C
command terminated with exit code 130
```

Create a network policy to allow traffic to the hello pod in the network-policy project from the sample-app pod in the different-namespace project via TCP on port 8080. Use the resource file at ~/DO280/labs/network-policy/allow-specific.yaml.

Use a text editor to replace the CHANGE_ME sections in the allow-specific.yaml file as follows:

...output omitted...
spec:
  podSelector:
    matchLabels:
      deployment: hello
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network: different-namespace
        podSelector:
          matchLabels:
            deployment: sample-app
      ports:
      - port: 8080
        protocol: TCP

Note

A solution is provided at ~/DO280/solutions/network-policy/allow-specific.yaml.

Apply the network policy from the allow-specific.yaml file with the oc create command.

[student@workstation network-policy]$ oc create -n network-policy -f \
    allow-specific.yaml
networkpolicy.networking.k8s.io/allow-specific created

View the network policies in the network-policy project.

[student@workstation network-policy]$ oc get networkpolicies -n network-policy
NAME             POD-SELECTOR       AGE
allow-specific   deployment=hello   11s
deny-all         <none>             5m6s

As the admin user, label the different-namespace namespace with the network=different-namespace label.

[student@workstation network-policy]$ oc login -u admin -p redhatocp
Login successful.

...output omitted...

Apply the network=different-namespace label with the oc label command.
```
[student@workstation network-policy]$ oc label namespace different-namespace \
    network=different-namespace
namespace/different-namespace labeled
```
Important
The allow-specific network policy uses labels to match the different-namespace namespace. By default, namespaces and projects do not get any labels automatically.

Confirm that the different-namespace label was applied.

[student@workstation network-policy]$ oc describe namespace different-namespace
Name:         different-namespace
Labels:       network=different-namespace
...output omitted...

[student@workstation network-policy]$ oc login -u developer -p developer
Login successful.

...output omitted...

Verify that the sample-app pod can access the IP address of the hello pod, but cannot access the IP address of the test pod.
1. Switch to the different-namespace project.
```
[student@workstation network-policy]$ oc project different-namespace
Already on project "different-namespace" on server "https://api.ocp4.example.com:6443".
```
2. Access the hello pod in the network-policy namespace with the oc rsh and curl commands via the 8080 port.
```
[student@workstation network-policy]$ oc rsh sample-app-d5f945-spx9q \
    curl 10.8.0.13:8080 | grep Hello
    <h1>Hello, world from nginx!</h1>
```
3. Verify that the hello pod cannot be accessed on another port. Because the network policy allows access only to port 8080 on the hello pod, requests to any other port are ignored and eventually time out. Wait a few seconds, and then press Ctrl+C to exit the curl command when no response occurs.
```
[student@workstation network-policy]$ oc rsh sample-app-d5f945-spx9q \
    curl 10.8.0.13:8181 | grep Hello
^C
command terminated with exit code 130
```
4. Verify that the test pod cannot be accessed from the sample-app pod. Wait a few seconds, and then press Ctrl+C to exit the curl command when no response occurs.
```
[student@workstation network-policy]$ oc rsh sample-app-d5f945-spx9q \
    curl 10.8.0.14:8080 | grep Hello
^C
command terminated with exit code 130
```
Verify if the hello route cannot access the hello pod.
1. Verify if the hello pod cannot be accessed via its exposed route.
```
[student@workstation network-policy]$ curl -s \
    hello-network-policy.apps.ocp4.example.com
    <h1>Hello, world from nginx!</h1>
```
  The lab environment is a single-node cluster. Because the ingress pods use host networking and the application pods are in the same node, the network policy does not block the traffic.

Create a network policy that allows traffic to the hello pod via the exposed route. Use the resource file at ~/DO280/labs/network-policy/allow-from-openshift-ingress.yaml.

This step does not have an effect on the lab environment, because the lab environment is a single-node cluster. On a cluster with multiple nodes, this step is required for correct ingress operation.

Use a text editor to replace the CHANGE_ME values in the allow-from-openshift-ingress.yaml file as follows:
```
...output omitted...
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
```
Note
A solution is provided at ~/DO280/solutions/network-policy/allow-from-openshift-ingress.yaml.

Apply the network policy from the allow-from-openshift-ingress.yaml file with the oc create command.

[student@workstation network-policy]$ oc create -n network-policy -f \
    allow-from-openshift-ingress.yaml
networkpolicy.networking.k8s.io/allow-from-openshift-ingress created

View the network policies in the network-policy namespace.

[student@workstation network-policy]$ oc get networkpolicies -n network-policy
NAME                           POD-SELECTOR       AGE
allow-from-openshift-ingress   <none>             10s
allow-specific                 deployment=hello   8m16s
deny-all                       <none>             13m

[student@workstation network-policy]$ oc login -u admin -p redhatocp
Login successful.

...output omitted...

Access the hello pod via the exposed route with the curl command.

[student@workstation network-policy]$ curl -s \
    hello-network-policy.apps.ocp4.example.com | grep Hello
        <h1>Hello, world from nginx!</h1>

Close the terminal window that contains the output of the display-project-info.sh script, and navigate to the home directory.
```
[student@workstation network-policy]$ cd
```

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 network-policy

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: Configure Network Policies

Note

Note

Important

Note