Art of Exploitation

•

OpenShift 4 Reencrypt Route: Comprehensive Guide

Introduction to OpenShift 4 Reencrypt Routes

OpenShift 4 provides three types of secured routes: Edge, Passthrough, and Reencrypt. This article delves deeply into the Reencrypt Route.

What’s a Reencrypt Route in OpenShift 4?

A reencrypt route ensures that traffic is reencrypted at a specific point in the network flow. To understand this, let’s first look at the general network flow for any OpenShift 4 route.

OCP 4 Reencrypt Route

 

  • User Access: The user opens the route URL in a web browser.
  • DNS Resolution: The DNS resolves the *.apps URL to the respective LoadBalancer.
  • Traffic Redirection: The LoadBalancer redirects the traffic to OpenShift 4 nodes where router pods are running.
  • Router Pod Handling: The router pods send the traffic to the respective application pods.

Router pods typically run in the openshift-ingress namespace.

$ oc get pod -n openshift-ingress
NAME                              READY   STATUS    RESTARTS   AGE
router-default-5598bf584f-g5hnc   1/1     Running   0          41h
router-default-5598bf584f-tsfvz   1/1     Running   0          41h

Where Does Traffic Get Reencrypted in a Reencrypt Route?

The network flow for a reencrypt route is similar to other OpenShift routes but with an additional step involving traffic reencryption.

OCP 4 Reencrypt Route

Network flow for reencrypt route is almost same just like any other OCP 4 route but with one additional difference related to traffic reencryption.

  • User Access: The user opens the route URL in a web browser.
  • DNS Resolution: The DNS resolves the *.apps URL to the respective LoadBalancer.
  • Traffic Redirection: The LoadBalancer redirects the traffic to OpenShift 4 nodes where router pods are running.
  • TLS Encryption by Router Pod: The router pod encrypts the traffic from the LoadBalancer using a default *.apps or custom certificate based on route configuration.
  • Traffic Reencryption: The traffic is TLS terminated at the router pod and reencrypted with the TLS certificate served by the application pod before being sent to the application pod.

For a reencrypt route to work in OpenShift 4, the application pod must accept traffic over HTTPS, meaning the TLS certificate must be configured inside the pod by the developer via methods like mounting with a secret or hardcoding in the container image.

Reencrypt Route Example

This example is based on the GitHub repo ay-garg/reencrypt-route-httpd. Feel free to contribute by raising a PR if there’s any scope for improvement or issues.

  • Generating CA Certificate and Private Key: First, generate the CA certificate and private key, which will be used to obtain the application TLS certificate and key.
$ openssl genrsa -out RootCA.key 2048
$ openssl req -new -key RootCA.key -out RootCA.csr -subj "/CN=customCA"
$ cat extension-file 
keyUsage               = critical,digitalSignature,keyEncipherment,keyCertSign
basicConstraints       = critical,CA:true
$ openssl x509 -req -days 1460 -in RootCA.csr -signkey RootCA.key -out RootCA.crt -sha256 -extfile extension-file
  • Creating the Application Certificate and Key: Create the application certificate and key using the CA certificate key-pair generated in the previous step.
$ openssl genrsa -out ayush.key 2048
$ openssl req -new -key ayush.key -out ayush.csr -subj "/CN=httpd-rencrypt.ayush.com"
$ openssl x509 -req -in ayush.csr -CA RootCA.crt -CAkey RootCA.key -CAcreateserial -out ayush.crt
  • Building the Container Image: Build a container image using tools like Podman or Docker. Use the provided Dockerfile in the example repository, build the image manually, and push it to your public image repository.
$ echo "Hello" >> index.html
$ cat Dockerfile
# Centos base images
FROM centos:centos7
# Update currently installed package and install httpd, mod_ssl, ca-certificates packages
RUN yum -y update && yum -y install \
    httpd \
    mod_ssl \
    ca-certificates
# Copy the index.html file
COPY index.html /var/www/html/
# Copy the certificate which will be used by the application
COPY ayush.crt /etc/pki/tls/certs/localhost.crt
# Copy the key which will be used by the application
COPY ayush.key /etc/pki/tls/private/localhost.key
# Copy the CA certificate
COPY RootCA.crt /usr/local/share/ca-certificates/RootCA.crt
RUN chmod 644 /usr/local/share/ca-certificates/RootCA.crt
RUN chmod 0710 /etc/pki/tls/private/localhost.key 
COPY RootCA.crt /etc/pki/ca-trust/source/anchors/
EXPOSE 443
CMD ["httpd", "-D", "FOREGROUND"]
$ docker build . -t <image-registry>/<username>/<image-name>:<tag>
$ docker push <image-registry>/<username>/<image-name>:<tag>
  • OpenShift 4 Prerequisites: Before running the pod, ensure that certain prerequisites are met in the OpenShift 4 cluster. Since the pod will use port 443, the anyuid SCC (Security Context Constraint) needs to be applied.
$ oc new-project httpd
$ oc adm policy add-scc-to-user anyuid -z default
  • Creating the Application Pod: Create the application pod with the newly created Docker image. Verify if the pod is serving traffic over HTTPS. You might need to SSH or debug into one of the OpenShift nodes to send a curl request to the pod IP for testing.
$ oc new-app --name httpd --image=<image-registry>/<username>/<image-name>:<tag>
$ oc get po -o wide
NAME             READY   STATUS    RESTARTS   AGE   IP             NODE             NOMINATED NODE   READINESS GATES
httpd-1-5lqtc    1/1     Running   0          1m    10.130.3.112   xyz-node-0.com   <none>
$ oc get nodes
NAME                  STATUS   ROLES     AGE   VERSION
xyz-node-0.com        Ready    worker    42h   v1.27.13+401bb48
...
...
oc debug node/xyz-node-0.com
Starting pod/xyz-node-0com-debug-4fgbc ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.0.70
If you don't see a command prompt, try pressing enter.
sh-4.4#
sh-4.4# chroot /host
sh-5.1#
sh-5.1# curl -kvv https://10.130.3.112
* About to connect() to 10.130.3.112 port 443 (#0)
*   Trying 10.130.3.112...
* Connected to 10.130.3.112 (10.130.3.112) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* 	subject: CN=httpd-rencrypt.ayush.com
* 	start date: Aug 8 05:41:16 2024 GMT
* 	expire date: Sep 8 05:41:16 2024 GMT
* 	common name: httpd-rencrypt.ayush.com
* 	issuer: CN=customCA
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.130.3.112
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Tue, 8 Aug 2024 05:53:22 GMT
< Server: Apache/2.4.37 (centos) OpenSSL/1.1.1
< Last-Modified: Tue, 8 Aug 2019 05:47:45 GMT
< ETag: "6-597ac9a73c240"
< Accept-Ranges: bytes
< Content-Length: 6
< Content-Type: text/html; charset=UTF-8
< 
Hello
* Connection #0 to host 10.130.3.112 left intact
  • Creating the Reencrypt Route: Finally, create the reencrypt route for the application pod with the necessary details, such as the destination CA certificate.
$ oc create route reencrypt httpd --service=httpd --hostname=httpd-rencrypt.ayush.com --dest-ca-cert=RootCA.crt
$ oc get route
NAME      HOST/PORT                  PATH      SERVICES   PORT      TERMINATION   WILDCARD
httpd     httpd-rencrypt.ayush.com             httpd      443-tcp   reencrypt     None
$ curl -kvv https://httpd-rencrypt.ayush.com
* About to connect() to httpd-rencrypt.ayush.com port 443 (#0)
*   Trying 10.74.249.97...
* Connected to httpd-rencrypt.ayush.com (10.74.249.97) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* 	subject: CN=*.cloudapps.ayush.com
* 	start date: Aug 08 19:45:34 2024 GMT
* 	expire date: Sep 08 19:45:35 2024 GMT
* 	common name: *.cloudapps.ayush.com
* 	issuer: CN=rootCA
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: httpd-rencrypt.ayush.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Tue, 08 Aug 2024 06:08:35 GMT
< Server: Apache/2.4.37 (centos) OpenSSL/1.1.1
< Last-Modified: Tue, 08 Aug 2024 05:47:45 GMT
< ETag: "6-597ac9a73c240"
< Accept-Ranges: bytes
< Content-Length: 6
< Content-Type: text/html; charset=UTF-8
< Set-Cookie: 0112d3b91eee77fe327ded7f932d7f1d=fac56a2b62d5ec9a227c0e573df9927c; path=/; HttpOnly; Secure
< Cache-control: private
< 
Hello
* Connection #0 to host httpd-rencrypt.ayush.com left intact

The destination CA certificate is required so that the router pod can trust the application pod certificate while reencryption occurs. Therefore, use the same CA certificate chain in the destination CA certificate field of the reencrypt route that signed the application pod certificates.

Important Links:

 

 

Leave a Reply

Discover more from Art of Exploitation

Subscribe now to keep reading and get access to the full archive.

Continue reading