DO280 - ch04s07

Bookmark this page

Lab: Network Security

Configure firewall rules to protect microservice communication, and also configure TLS encryption between those microservices and for external access.

Outcomes

Encrypt internal traffic between pods by using TLS service secrets that OpenShift generates.
Route external traffic to terminate TLS within the cluster.
Restrict ingress traffic for a group of pods by using network policies.

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

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

This command ensures that the environment is ready and copies the necessary files for this exercise.

This command also deploys an API that is composed of a product and a stock microservice to the network-review project.

The product microservice is the entry point to the API. The stock microservice provides only additional information to the product response. If the product microservice cannot reach the stock microservice, then the product microservice returns the -1 value.

The developer deployed the API without the security configuration. You must configure TLS for end-to-end communications and restrict the ingress to pods for both microservices.

To complete the exercise, the following URLs must respond without errors:

https://stock.network-review.svc.cluster.local/product/1
https://product.apps.ocp4.example.com/products

Note

The lab start deploys solution files in the ~/DO280/solutions/network-review/ directory.

Instructions

Log in to your OpenShift cluster as the admin user with the redhatocp password.
Use the oc login command to log in to your OpenShift cluster as the admin user.
[student@workstation ~]$ oc login -u admin -p redhatocp \ https://api.ocp4.example.com:6443 Login successful. ...output omitted...
Create the stock-service-cert secret for the OpenShift service certificate to encrypt communications between the product and the stock microservices.
Change to the network-review project.
[student@workstation ~]$ oc project network-review Now using project "network-review" on server "https://api.ocp4.example.com:6443"
Change to the ~/DO280/labs/network-review directory to access the lab files.
[student@workstation ~]$ cd ~/DO280/labs/network-review
Edit the stock-service.yaml manifest to configure the stock service with the service.beta.openshift.io/serving-cert-secret-name: stock-service-cert annotation. This annotation creates the stock-service-cert secret with the service certificate and the key.
apiVersion: v1 kind: Service metadata: name: stock namespace: network-review annotations: service.beta.openshift.io/serving-cert-secret-name: stock-service-cert spec: ...output omitted...
Apply the stock service changes by using the oc apply command.
[student@workstation network-review]$ oc apply -f stock-service.yaml service/stock configured
Verify that the stock-service-cert secret contains a valid certificate for the stock.network-review.svc hostname in the tls.crt secret key. Decode the secret output with the base64 command by using the -d option. Then, use the openssl x509 command to read the output from standard input, and use the -text option to print the certificate in text form.
[student@workstation network-review]$ oc get secret stock-service-cert \ --output="jsonpath={.data.tls\.crt}" \ | base64 -d \ | openssl x509 -text ...output omitted... X509v3 Subject Alternative Name: DNS:stock.network-review.svc, DNS:stock.network-review.svc.cluster.local ...output omitted...

Configure TLS on the stock microservice by using the stock-service-cert secret that OpenShift generates.

Use the following settings in the deployment to configure TLS:

Set the path for the certificate and key to /etc/pki/stock/.
Set the TLS_ENABLED environment variable to "true".
Update the liveness and readiness probes to use TLS.
Change the service to listen on the standard HTTPS 443 port.

Edit the stock-deployment.yaml file to mount the stock-service-cert secret on the /etc/pki/stock/ path.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stock
  namespace: network-review
spec:
...output omitted...
    spec:
      containers:
        - name: stock
...output omitted...
          env:
            - name: TLS_ENABLED
              value: "false"
          volumeMounts:
            - name: stock-service-cert
              mountPath: /etc/pki/stock/
      volumes:
        - name: stock-service-cert
          secret:
            defaultMode: 420
            secretName: stock-service-cert

Edit the stock deployment in the stock-deployment.yaml file to configure TLS for the application and for the liveness and readiness probes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stock
  namespace: network-review
spec:
...output omitted...
    spec:
      containers:
      - name: stock
...output omitted...
        ports:
          - containerPort: 8085
        readinessProbe:
          httpGet:
            port: 8085
            path: /readyz
            scheme: HTTPS
        livenessProbe:
          httpGet:
            port: 8085
            path: /livez
            scheme: HTTPS
        env:
          - name: TLS_ENABLED
            value: "true"
...output omitted...

Apply the stock deployment updates by using the oc apply command.

[student@workstation network-review]$ oc apply -f stock-deployment.yaml
deployment/stock configured

Edit the stock-service.yaml file to configure the stock service to listen on the standard HTTPS 443 port.

apiVersion: v1
kind: Service
metadata:
  name: stock
  namespace: network-review
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: stock-service-cert
spec:
  selector:
    app: stock
  ports:
    - port: 443
      targetPort: 8085
      name: https

Apply the stock service changes by using the oc apply command.

[student@workstation network-review]$ oc apply -f stock-service.yaml
service/stock configured

Configure TLS between the product and the stock microservices by using the internal Certificate Authority (CA) from OpenShift.

The product microservice requires the following settings:

The CERT_CA environment variable that is set to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem to access the OpenShift CA
The STOCK_URL environment variable with the HTTPS protocol

Edit the configuration map in the service-ca-configmap.yaml file to add the service.beta.openshift.io/inject-cabundle: "true" annotation. This annotation injects the OpenShift internal CA into the service-ca configuration map.
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: service-ca
  namespace: network-review
  annotations:
    service.beta.openshift.io/inject-cabundle: "true"
data: {}
```

Create the service-ca configuration map by using the oc create command.

[student@workstation network-review]$ oc create -f service-ca-configmap.yaml
configmap/service-ca created

Verify that OpenShift injects the CA certificate by describing the service-ca configuration map with the oc describe command.

[student@workstation network-review]$ oc describe configmap service-ca
Name:         service-ca
Namespace:    network-review
Labels:       <none>
Annotations:  service.beta.openshift.io/inject-cabundle: true

Data
====
service-ca.crt:
-----
-----BEGIN CERTIFICATE-----

Edit the product-deployment.yaml file to configure the product deployment to use the service-ca configuration map, to add the CERT_CA environment variable, and to update the STOCK_URL environment variable to use the HTTPS protocol.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: product
  namespace: network-review
spec:
...output omitted...
    spec:
      containers:
        - name: product
...output omitted...
          env:
            - name: CERT_CA
              value: "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem"
            - name: TLS_ENABLED
              value: "false"
            - name: STOCK_URL
              value: "https://stock.network-review.svc"
          volumeMounts:
             - name: trusted-ca
               mountPath: /etc/pki/ca-trust/extracted/pem
      volumes:
        - name: trusted-ca
          configMap:
            defaultMode: 420
            name: service-ca
            items:
              - key: service-ca.crt
                path: tls-ca-bundle.pem

Apply the product deployment updates by using the oc apply command.

[student@workstation network-review]$ oc apply -f product-deployment.yaml
deployment/product configured

Send a request to the https://stock.network-review.svc/product/1 URL from product deployment to verify that you can query the stock microservice by using HTTPS. Run the oc exec command to run the curl command to send a request to the stock microservice.
```
[student@workstation network-review]$ oc exec deployment/product \
  -- curl -s https://stock.network-review.svc/product/1
10
```

Configure TLS on the product microservice by using a signed certificate by a corporate CA to accept TLS connections from outside the cluster.

You have the CA certificate and the signed certificate for the product.apps.ocp4.example.com domain in the certs directory of the lab.

Use the following settings in the deployment to configure TLS:

Set the path for the certificate and key to /etc/pki/product/.
Set the TLS_ENABLED environment variable to the "true" value.
Update the liveness and readiness probes to use TLS.

Create the passthrough-cert secret by using the product.pem certificate and the product.key key from the lab directory.

[student@workstation network-review]$ oc create secret tls passthrough-cert \
  --cert certs/product.pem --key certs/product.key
secret/passthrough-cert created

Edit the product deployment to mount the passthrough-cert secret on the /etc/pki/product/ path.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: product
spec:
...output omitted...
    spec:
      containers:
        - name: product
...output omitted...
          volumeMounts:
            - name: passthrough-cert
              mountPath: /etc/pki/product/
            - name: trusted-ca
              mountPath: /etc/pki/ca-trust/extracted/pem
      volumes:
        - name: passthrough-cert
          secret:
            defaultMode: 420
            secretName: passthrough-cert
        - name: trusted-ca
          configMap:
            defaultMode: 420
            name: service-ca
            items:
              - key: service-ca.crt
                path: tls-ca-bundle.pem

Edit the product deployment to configure TLS for the application and for the liveness and readiness probes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: product
spec:
...output omitted...
    spec:
      containers:
      - name: product
...output omitted...
        ports:
          - containerPort: 8080
        readinessProbe:
          httpGet:
            port: 8080
            path: /readyz
            scheme: HTTPS
        livenessProbe:
          httpGet:
            port: 8080
            path: /livez
            scheme: HTTPS
        env:
          - name: TLS_ENABLED
            value: "true"
          - name: STOCK_URL
            value: "https://stock.network-review.svc"
...output omitted...

Apply the product deployment updates by using the oc apply command.

[student@workstation network-review]$ oc apply -f product-deployment.yaml
deployment.apps/product configured

Expose the product microservice to outer cluster access by using the FQDN in the signed certificate by the corporate CA. Use the product.apps.ocp4.example.com hostname.
Create a passthrough route for the product service by using the product.apps.ocp4.example.com hostname.
[student@workstation network-review]$ oc create route passthrough product-https \ --service product --port 8080 \ --hostname product.apps.ocp4.example.com route.route.openshift.io/product-https created
Verify that you can query the product microservice from outside the cluster by using the curl command with the ca.pem CA certificate.
[student@workstation network-review]$ curl --cacert certs/ca.pem \ https://product.apps.ocp4.example.com/products [{"id":1,"name":"rpi4_4gb","stock":10},{"id":2,"name":"rpi4_8gb","stock":5}]

Configure network policies to accept only ingress connections to the stock pod on the 8085 port that come from a pod with the app=product label.

Edit the stock-ingresspolicy.yaml to add the network policy specification.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress-stock-policy
spec:
  podSelector:
    matchLabels:
      app: stock
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: product
      ports:
        - protocol: TCP
          port: 8085

Create the network policy.

[student@workstation network-review]$ oc create -f stock-ingresspolicy.yaml
networkpolicy.networking.k8s.io/stock-ingress-policy created

Configure network policies to accept only ingress connections to the product pod on the 8080 port that come from the OpenShift router pods.

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: product-ingress-policy
spec:
  podSelector:
    matchLabels:
      app: product
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              policy-group.network.openshift.io/ingress: ""
      ports:
        - protocol: TCP
          port: 8080

Create the network policy.

[student@workstation network-review]$ oc create -f product-ingresspolicy.yaml
networkpolicy.networking.k8s.io/product-ingress-policy created

Change to the home directory.

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