This document showcases the process of how to deploy the Prisma Cloud Compute console in a Kubernetes cluster on any cloud provider and use a NGINX Ingress controller as a proxy for this console.
Purpose
For many enterprises, moving production workloads into Kubernetes brings additional challenges and complexities around application traffic management. An Ingress controller abstracts away the complexity of Kubernetes application traffic routing and provides a bridge between Kubernetes services and external ones.
What’s Next?
You’ll see how to deploy the Prisma Cloud Compute console behind an NGINX ingress using Mutual Authentication by either reusing the certificates that the console provides for defender - consolo communication, or using your own custom certificates.
Objective
Discover how to deploy an Ingress controller to manage the Web UI or API access to the Prisma Cloud Compute console and the defender-console communication.
Environment
This document requires you to have the following tools in place:
Run the following command:
It's recommended to follow your cloud provider’s instructions on how to deploy a nginx ingress resource.
You need to obtain the public IP address or common name of the ingress service:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEIngress-nginx-controller LoadBalancer xx.xx.xx.xx PUBLIC_IP 80:xx/TCP,443:xx/TCP 44h |
Figure 1: kubectl get svc command output_palo-alto-networks
Create two DNS records, one for accessing the Prisma Cloud Compute console web UI. In this document, the variable is named CONSOLE_FQDN which is “console.example.com”. Another for the defender - console communication is named as DEFENDER_FQDN which can be like “defender.example.com”.
Download the appropriate release from the Support Portal and then create the prisma_cloud folder and unpack the release tarball:
Check if your cluster has any storage class installed by running the following command:
|
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE default (default) xxxxxxxxxx Delete WaitForFirstConsumer true 120d |
Figure 2: storage classes installed in the kubernetes cluster_palo-alto-networks
As long as your cluster has a storage class we can continue, otherwise you need to install one. We suggest relying on your cloud provider.
The PLATFORM can be linux, osx or windows.
You will be asked to enter the product token received as part of the purchase of Prisma Cloud Compute subscription.
In this scenario, we are going to use the default storageClass so it is not required to declare which storage class we are using, but if you want to set up your own storageClass you can use the flag --storage-class YOUR_STORAGE_CLASS_NAME.
There are two options for the certificates:
In this scenario, we’ll use the second option:
Create a file console_ingress.yaml with the following content:
apiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: console-ingressnamespace: twistlockannotations:kubernetes.io/ingress.class: "nginx"nginx.ingress.kubernetes.io/ssl-redirect: "true"nginx.ingress.kubernetes.io/backend-protocol: HTTPSspec:rules:- host: ${CONSOLE_FQDN}http:paths:- path: /pathType: Prefixbackend:service:name: twistlock-consoleport:number: 8083tls:- secretName: console-tlshosts:- ${CONSOLE_FQDN} |
Figure 3: console ingress manifest_palo-alto-networks
Apply the file created:
In your browser input the following URL:
You’ll be asked to create an account and input your license key.
On the Prisma Cloud Compute console, go to Manage > Defenders > Names > Add SAN, and input the value of DEFENDER_FQDN:
Figure 4: Console Subject Alternative names_palo-alto-networks
On the Prisma Cloud Compute console, go to Manage > Defenders > Deployed Defenders > Manual Deploy. From the dropdown menu, choose DEFENDER_FQDN, set communication port to 443 and other relevant parameters, and then click on Download YAML.
Figure 5: Manual deployment of Defenders_palo-alto-networks
This method is used if you have access to the console pod via kubectl.
Get the twistlock console pod full name:
|
NAME READY STATUS RESTARTS AGE twistlock-console-xxxxxxxxx-xxxxx 1/1 Running 0 106m |
Figure 6: kubectl get pods command output_palo-alto-networks
Copy the files defender-ca.pem, defender-server-cert.pem, defender-server-key.pem, defender-client-cert.pem, defender-server-client.pem and service-parameter found in directory /var/lib/twistlock/certificates to the a local directory.
The files defender-ca.pem, defender-client-cert.pem and defender-client-key.pem can be found in the daemonset.pem file in the secret twistlock-secrets, but are encoded in base 64.
Create a file defender_ingress.yaml with the following content:
apiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: defender-ingressnamespace: twistlockannotations:kubernetes.io/ingress.class: "nginx"nginx.org/websocket-services: "twistlock-console"nginx.ingress.kubernetes.io/auth-tls-match-cn: ${DEFENDER_FQDN}nginx.ingress.kubernetes.io/auth-tls-secret: twistlock/ca-secretnginx.ingress.kubernetes.io/auth-tls-verify-client: "on"nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"nginx.ingress.kubernetes.io/backend-protocol: HTTPSnginx.ingress.kubernetes.io/proxy-ssl-secret: twistlock/proxy-ca-secretnginx.ingress.kubernetes.io/proxy-ssl-verify: "on"nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "1"nginx.ingress.kubernetes.io/configuration-snippet: |proxy_ssl_name "$DEFENDER_FQDN";spec:rules:- host: ${DEFENDER_FQDN}http:paths:- path: /pathType: Prefixbackend:service:name: twistlock-consoleport:number: 8084tls:- secretName: proxy-tlshosts:- ${DEFENDER_FQDN} |
Figure 7: defender ingress manifest_palo-alto-networks
Apply the file created:
The ingress created is meant to perform Mutual Authentication between in the frontend and in the backend.
Apply the modified daemonset.yaml file on different kubernetes context
This method assumes that you don’t have access to the console pod due to internal policies or admission control, and you have not deployed any defender as of yet. If you have defenders deployed, you’ll need to update the certificates or do a mix-up with the previous method.
This step is not required, but recommended. Run the following commands:
You’ll be asked to input a passphrase. After that, you can remove the file mypass
1. Generate an encrypted root CA key
2. Create and self-sign the root certificate
1. Create SAN Names file
2. Create a defender server key
3. Generate a defender server CSR
4. Create a defender server certificate signed by the root CA certificate
Step 4: Generate a defender-client certificate for the defender
1. Create the defender client key
2. Generate defender client CSR
3. Create the defender client certificate
1. Create the proxy key
2. Generate the proxy CSR
3. Create the proxy certificate
This step is optional because you can substitute this certificate and key for the others you’ve generated, but is just as a best practice.
You can check that the SAN, CN and OU values are correct.
1. Create custom certificates secret for the console
2. Add the following volume and volume mount to the file twistlock_console.yaml and apply changes:
apiVersion: apps/v1kind: Deploymentmetadata:name: twistlock-consolenamespace: twistlock...spec:...template:...spec:...containers:- name: twistlock-console...volumeMounts:- name: custom-certificatesmountPath: "/var/lib/twistlock/custom-certificates"...volumes:- name: custom-certificatessecret:secretName: console-custom-certdefaultMode: 256... |
Figure 8: Mounting custom certificates on the Console deployment_palo-alto-networks
3. Create the custom certificates for the defender
4. Add the following volume and volume mount to the file daemonset.yaml you’ve downloaded in step G:
apiVersion: apps/v1kind: DaemonSetmetadata:name: twistlock-defender-dsnamespace: twistlock...spec:...template:...spec:...containers:- name: twistlock-defender...volumeMounts:- name: custom-certificatesmountPath: "/var/lib/twistlock/custom-certificates"...volumes:- name: custom-certificatessecret:secretName: defender-custom-certdefaultMode: 256... |
Figure 9: Mounting custom certificates on the Defender DaemonSet_palo-alto-networks
Generate secrets for Ingress
You could replace the values proxy-cert.pem and proxy-key.pem from in secret proxy-ca-secret for defender-client-cert.pem and defender-client-key.pem respectively.
You could also replace the values proxy-cert.pem and proxy-key.pem from in secret proxy-tls for defender-server-cert.pem and defender-server-key.pem respectively.
Step 8: Create the Console Defender Ingress
Use the same process found in Part 2 - Step 4 - Console Certificates Methods .
Step 9: Deploy the Defender
Only apply the modified daemonset.yaml file on different kubernetes context
After you’ve performed the preceding steps, go to Manage > Defenders > Deployed Defenders. It should look like this:
Figure 10: Verifying Defenders’ connectivity_palo-alto-networks
If this is not the case, follow up the next steps.
For this step and the following, it’s recommended to spin up a test deployment or pod inside the cluster and namespace where the defender is being deployed. In this case, will be created a ubuntu deployment inside the twistlock namespace.
After being deployed and the container is running, access the container and install the package dnsutils:
Now verify that the DNS resolution works for DEFENDER_FQDN:
|
Correct answer: Server: x.x.x.x Address: x.x.x.x#53 Non-authoritative answer: Name: defender.example.com Address: PUBLIC_IP Incorrect answers: # 1 Server: x.x.x.x Address: x.x.x.x#53 server can't find defender.example.com: NXDOMAIN # 2 Server: x.x.x.x Address: x.x.x.x#53 Non-authoritative answer: Name: defender.example.com Address: WRONG_PUBLIC_IP |
Figure 11: Verifying DNS resolution_palo-alto-networks
If you receive the incorrect answer #1, check your cluster DNS settings.
If you receive the incorrect answer #2, check your Domain Name records or wait until the DNS Record set has been renewed globally.
If you receive a correct answer, proceed to the next step.
Inside the test pod, install the openssl command and test connectivity:
|
Correct answer: CONNECTED(00000003) depth=0 CORRECT SERVER CERTIFICATE PARAMETERS verify error:num=18:self-signed certificate verify return:1 depth=0 CORRECT SERVER CERTIFICATE PARAMETERS verify return:1 ... Incorrect answers: # 1 CONNECTED(00000003) depth=0 WRONG SERVER CERTIFICATE PARAMETERS verify error:num=18:self-signed certificate verify return:1 depth=0 WRONG SERVER CERTIFICATE PARAMETERS verify return:1 ... # 2 HANG UP |
Figure 12: Test Defender - Console connectivity_palo-alto-networks
If you receive an incorrect answer #1, check the proxy-tls secret, or check the nginx ingress controller logs.
If you receive incorrect answer #2, check for any restriction on the firewall of the nodes, the security groups, access control lists or others that might restrict the connectivity.
If you receive a correct answer, continue with the next step.
Inside the annotation nginx.ingress.kubernetes.io/configuration-snippet of the defender_ingress.yaml you can try out any of the values that are set up as SAN like twistlock-console or any other
If the iterative troubleshooting does not work, continue to step 4.
Look for any misconfiguration on the nginx controller level:
And Defender daemonset level:
Additional Information
In this article, we showed you how to deploy the Prisma Cloud Compute console behind a NGINX ingress. We covered how to install the NGINX ingress controller, how to deploy and configure the console, how to create the ingresses for the console web UI and defender - console communication, how to deploy a DaemonSet defender and how to troubleshoot some common errors found in this process.
We showed that for a successful communication between the defender and the console, it is required to manage mutual authentication between the defender - ingress and ingress - console communication. This mutual authentication can be performed using the certificates that the console already provides or any custom certificates. That’s it!
[2] Setup NGINX Ingress for EKS
[3] Create an ingress controller in AKS
[4] Ingress with NGINX controller on GKE
[5] NGINX Ingress Configuration
[6] Create Client-Server certificates
[7] Prisma Cloud configure custom certificates
[8] Cert-Manager
Juan Montufar and Sriram Choudary Nimmagadda are senior customer success engineers specializing in Prisma Cloud, Next-Generation Firewall, AWS, Azure, GCP, containers and Kubernetes. They use collaborative approaches to break down complex problems into solutions for global enterprise customers and leverage their multi-industry knowledge to inspire success.
