7. Configure Network Security

Question 1

1. Configure networking components

Answer 1

NetworkType - Cidr - ServiceNetwork
oc get network.config.openshift.io cluster -o yaml

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  externalIP:
    policy: {}
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16
status:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  clusterNetworkMTU: 1400
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16 Network Operator configuration - routingViaHost   # To Enable `routingViaHost` , set it as `true` with   oc edit networks.operator cluster

Question 2

2. Troubleshoot software defined networking

Answer 2

Apply the usual methods, don’t you think?

Question 3

3. Create and edit external routes

Answer 3

Use oc create route edge and oc create route passthrough to create routes.

Find out more details in section the Secure external and internal traffic using TLS certificates below.

Question 4

4. Control cluster network ingress

Answer 4

Something to add here ?

Question 5

5. Secure external and internal traffic using TLS certificates

Answer 5

Secure external and internal traffic using TLS certificates
Securing Routes

Routes can be either secured or unsecured. Secure routes support several types of transport layer security (TLS) termination to serve certificates to the client.
A secured route specifies the TLS termination of the route. The following termination types are available:

Edge: With edge termination, TLS termination occurs at the router, before the traffic is routed to the pods. The router serves the TLS certificates, so you must configure them into the route; otherwise, OpenShift assigns its own certificate to the router for TLS termination.

Passthrough: With passthrough termination, encrypted traffic is sent straight to the destination pod without TLS termination from the router. In this mode, the application is responsible for serving certificates for the traffic.

Re-encryption: is a variation on edge termination, whereby the router terminates TLS with a certificate, and then re-encrypts its connection to the endpoint, which might have a different certificate. Find out more here

Secure Routes
# Securing Applications with Edge Routes

## With Edge termination generating certificate
oc create route edge –service api-frontend –hostname api.apps.acme.com

## by passing your own certificate to the Edge termination
oc create route edge –service api-frontend –hostname api.apps.acme.com –key api.key –cert api.crt

# With Passthrough
## Create a TLS secret that contains the certificate
## Mount the certificate as volume in your pods/deployements…
## And assume your app is configured to use it

oc create secret tls todo-certs –cert certs/training.crt –key certs/training.key

### mount secret as volume
oc set volume deployment/todo-https –add –type secret -secret-name todo-certs –mount-path /usr/local/etc/ssl/certs

### create passthrough route
oc create route passthrough todo-https –service todo-https –port 8443 –hostname todo-https.apps.ocp4.example.com
Find out more in Configuring Routes documentation.
To learn more about SSl certificate generation, see SSL documentation.
Secure internal traffic
Service certificate

OpenShift provides the service-ca controller to generate and sign service certificates for internal traffic. The service-ca controller creates a secret that it populates with a signed certificate and key.

A deployment can mount this secret as a volume to use the signed certificate.Additionally, client applications need to trust the service-ca controller CA.

Find out more in service serving certificates documentation.

Service Certificate Creation

To generate a certificate and key pair, apply the service.beta.openshift.io/serving-cert-secret-name=your-secret annotation to a service.
The service-ca controller creates the your-secret secret in the same namespace if it does not exist, and populates it with a signed certificate and key pair for the service.

Annotations
oc annotate service hello \ 1
service.beta.openshift.io/serving-cert-secret-name=hello-secret 2
service/hello annotated
After OpenShift generates the secret, you must mount the secret in the application deployment. The location to place the certificate and key is application-dependent.

TLS Certficate
spec:
template:
spec:
containers:
- name: hello
volumeMounts:
- name: hello-volume
mountPath: /etc/pki/nginx/
volumes:
- name: hello-volume
secret:
defaultMode: 420
secretName: hello-secret
items:
- key: tls.crt
path: server.crt
- key: tls.key
path: private/server.key
Client Service Application Configuration

For a client service application to verify the validity of a certificate, the application needs the CA bundle that signed that certificate.
The service-ca controller injects the CA bundle when you apply the service.beta.openshift.io/inject-cabundle=true annotation to an object.

You can apply the annotation to configuration maps, API services, custom resource definitions (CRD), mutating webhooks, and validating webhooks.

Example
## apply the annotation to a configmap
oc create configmap ca-bundle

oc annotate configmap ca-bundle \
service.beta.openshift.io/inject-cabundle=true
configmap/ca-bundle annotated

## mount the ca-bundle configmap in the client pod/deployment
## e.g pod
apiVersion: v1
kind: Pod
metadata:
name: client
spec:
containers:
- name: client
image: registry.ocp4.example.com:8443/redhattraining/hello-world-nginx
resources: {}
volumeMounts:
- mountPath: /etc/pki/ca-trust/extracted/pem
name: trusted-ca
volumes:
- configMap:
defaultMode: 420
name: ca-bundle
items:
- key: service-ca.crt
path: tls-ca-bundle.pem
name: trusted-ca
Alternatives to Service Certificates

Other options can handle TLS encryption inside an OpenShift cluster, such as a service mesh or the certmanager operator.

You can use the certmanager operator to delegate the certificate signing process to a trusted external service, and also to renew a certificate.

You can also use Red Hat OpenShift Service Mesh for encrypted service-to-service communication and for other advanced features.

Question 6

6. Configure application network policies

Answer 6

There are the same as Kubernetes Network Policies

Here is Openshift related documentation

To allow traffic from only router/ingress pods, use the label network.openshift.io/policy-group: ingress to match ingress namespace

NetworkPolicy
# The following network policy applies to all pods with the deployment=”product-catalog” label in the network-1 namespace.
# The network-2 namespace has the network=network-2 label.
# The policy allows TCP traffic over port 8080 from pods whose label is role=”qa” in namespaces with the network=network-2 label.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: network-1-policy
namespace: network-1
spec:
podSelector: 1
matchLabels:
deployment: product-catalog
policyTypes:
- Ingress
ingress: 2
- from: 3
- namespaceSelector:
matchLabels:
network: network-2
podSelector:
matchLabels:
role: qa
ports: 4
- port: 8080
protocol: TCP