Prisma Cloud Compute certificates
This article summarizes all the certificates used by Prisma Cloud Compute. For each certificate, you can learn more about its functionallity, signing CA, and your customization options.
Customizing certificates is only allowed for Prisma Cloud Compute edition.
Prisma Cloud edition
Console TLS communication
Console Web and API certificate
Web browser, API and twistcli access to console
Manage > Authentication > System certificates > TLS certificate for Console > Concatenate public cert and private key
Your organization CA
Compute edition, Enterprise edition
To enforce Docker access control, client certs should be installed on any host where the docker client can be run.
Clients (users) access to remote Docker Engine instances
Customize your own certificates for your clients
Explicit list of trusted certificates can be defined under
Manage > Authentication > System certificates > Client certificates > Explicit certificate trust list
Manage > Authentication > System certificates > Client certificates > CA certificate
Compute edition, Enterprise edition
Certificate-based authentication to Console
Clients access the Console
No CA by default
Enable Console verification of the client’s CA certificate when accessing the Console.
Define CA under
Manage > Authentication > System certificates > Certificate-based authentication to Console > CA certificate
Defender client certificate (Defender side)
Defender CA (defender-ca.pem)
Compute edition, not relevant for Enterprise edition (uses API token)
Admission certificate (admission-cert.pem)
Admission webhook authentication with Prisma Cloud Defender
Defender CA (defender-ca.pem)
Compute edition, Enterprise edition
Console TLS communication certificates
You can secure access to Console with your own digital certificate. By default, Prisma Cloud accesses the Console’s web portal and API with a self-signed certificate.
The self-managed certificate generated by Console is valid for three years. 90 days prior to expiration, Prisma Cloud will let you rotate it (a banner will appear at the top of the UI). After rotating Console’s certificate, you must restart the Console.
When you access Console’s web portal with this setup, for example, the browser flags the portal as untrusted with a warning message. The following screenshot shows the warning message in Chrome:
You can resolve these warnings by installing your own certificate that proves your server’s identity to the client. With the proper certificate, users are taken directly to Console, and the green padlock in the address bar indicates that the site is trusted.
Creating certificates is outside the scope of this article. For more information about how SSL and certificates secure a site, see How does HTTPS actually work.
Prisma Cloud secures the communication between various actors and entities with certificates. These certificates are automatically generated and self-signed during the Prisma Cloud install process. They secure communication between:
- Users and the Console web portal
- Users and the Console API
- Console and the Prisma Cloud Intelligence Stream
The following options control the properties of the certificates generated during the install process. The default values for these options are typically adequate.
Note that these settings only change the values used when creating self-signed certificates. Thus, users accessing the Console will still see warning messages because the certificates are not signed by a trusted certificate authority (CA). To configure the Console to use a certificate signed by a trusted CA, follow the steps later in this article.
These options can be found in twistlock.cfg under the General Configuration section:
Specifies the Common Name to be used in the certificate generated by Prisma Cloud for the host that runs Console. The Common Name is typically your host name plus domain name. For example, it might be www.example.com or example.com.
You can also control the Subject Alternative Names (SANs) in Console’s certificate.
Securing access to Console with custom certificates
Secure access to Console with your own custom certificates.
- Your certs have been generated by a commercial Certificate Authority (CA) or with your own Public Key Infrastructure (PKI). You should have the following files on hand:
- Make sure that the private key starts and ends with:----BEGIN PRIVATE KEY---- ----END PRIVATE KEY----or:-----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----Open Prisma Cloud Console in a browser.Navigate toManage > Authentication > System Certificates.Concatenate your public certificate and private key into a single PEM file.$ cat server.crt server.key > server-cert.pemOpen theTLS certificate for Consolesection
Verify that your certs have been correctly installed.Open your browser, and navigate to: https://<CONSOLE_HOSTNAME>:8083If you see the locked padlock icon, you have installed your certs correctly.HTTP Public Key Pinning (HPKP) was a security feature that used to tell a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of Man In The Middle (MITM) attacks with forged certificates. This feature is no longer recommended. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
- Upload the PEM file into theConcatenate public cert and private key (e.g., cat server-cert.pem server-key.pem)
Docker role-based access control certificates
These certificates settings are related to the Docker access control feature. Using the Docker access control you can validate that Docker commands only run from remote machines through Defender on port 9998. Any user running Docker commands on port 9998 must be authenticated and authorized. By default the Console generates certificates for users to authenticate to Defender. Any command run against Defender must also be explicitly allowed.
Prisma Cloud lets you use your own certificates for Docker access control. Customize the Docker access control certificates, by providing Prisma Cloud the CA that signs the client (user) certificates. You can also specify an explicit list for client trusted certificates.
- External certification authority (CA) section will be visible only to an Admin role user.
- All trusted certificate information will be retrieved from the certificate itself, so the user doesn’t have to manually add info such as CN, issuer etc.
- Only the public portion of a user certificate should be added to the explicit trust list. Private keys are not required and should be excluded from this process.
Setting up your custom certs
To set up your custom certs:
- Open Console, and go toManage > Authentication > System certificates.
- Open theCA certificatecard.
- UnderCA certificat, upload CA certificate to trust.Once this configuration is enabled, users must copy their keys (both public and private) to the host they’re using to run commands with docker or kubectl. Though the path can be referenced in each command, it’s usually simpler to place them in the default directory that docker looks in for certificates (~/.docker).Each user certificate used with Prisma Cloud must have the user’s CN embedded in the Subject field of the certificate. You can validate these settings by running the following command against the certificate:$ openssl x509 -in .docker/cert.pem -text | grep Subj Subject: CN=usernameFinally, Docker requires that the CA certificate used to sign the server certificate on the nodes Prisma Cloud is protecting must also be in the ~/.docker folder, in a file called ca.pem. Because the 'server' certificate used in this deployment model is still generated by Prisma Cloud, this means that on each host where you’re running docker or kubectl commands, you must also add the CA certificate to this folder.
- You can also choose to setExplicit certificate trust listtoON(this configuration is optional)Explicit certificate trust list allows you to create a list of explicitly trusted custom certificates. A typical use case of this feature would be when you have multiple certificates issued to a given user, but only want specific ones to be available for use with Prisma Cloud. By adding an explicit trust list, you can control what certificates can be used, as Prisma Cloud compares any certificates presented to it against the allowed trusted certificates list. This way, a user using a certificate not in the explicitly allowed list will not be able to use the certificate with Prisma Cloud, even if it was issued by a trusted CA. Note that this feature is valid only when a custom CA is configured. When enabled, this feature allows users to add new certificates to a table by uploading public certificates in PEM format.
- ClickAdd certificate, copy the PEM-formatted public certificate which was issued by the trusted CA, then clickAdd.When a custom certificate is provided to Prisma Cloud, it first checks the certificate against this list. If the certificate is matched to an entry in the list, then the previously existent flow continues. If the certificate is not in the trusted list, then the authentication fails with an error 'Certificate not in certificate trust list configured in Prisma Cloud'.
Certificate-based authentication to Console
This feature allows the Console to verify the client’s CA certificate when accessing the Console. Use certificates from an implicitly trusted CA for securing the TLS connection. To enable this feature follow the steps below:
- Open Console, and go toManage > Authentication > System Certificates.
- Open theCertificate-based authentication to Consolecard.
- UnderConsole Authenticationupload the CA certificate(s) in PEM format, then clickSave.If you have multiple CAs, such as a root CA and several issuing CAs, you must add all these certificates into the PEM file. The order of certificates in the PEM file should be from the lowest tier of the hierarchy to the root. For example, if you have a 3 tier hierarchy that looks like this:->RootCA ->IntermediateCA ->IssuingCA1 ->IssuingCA2Your PEM file should be ordered as IssuingCA1, IssuingCA2, IntermediateCA, RootCA. To create such a PEM file, you’d get the public keys of each CA in PEM format and concatenate them together:$ cat IssuingCA1.pem IssuingCA2.pem IntermediateCA.pem RootCA.pem > CAs.pem
- Container Defenders (Windows and Linux)
- Host Defenders (Windows and Linux)
- DaemonSet Defenders
- App-Embedded Defenders, including Fargate
Console-Defender communication certificates
By design, Console and Defender don’t trust each other and use certificates to mutually authenticate when Defender establishes a connection with Console. The certificates for Console-Defender communication are issued by the Defender CA (defender-ca.pem). The Defender CA is a self-signed CA, generated by Console, and it’s valid for three years. Console is considered the server and Defender the client. Console generates certs for each party, and signs them with the Defender CA.
Prisma Cloud automatically rotates the Defender CA and related server and client certificates 1.5 years before the Defender CA expires. Console and Defender use the old certs until the old Defender CA expires.
New Defenders, deployed after the certificates have been rotated, automatically get both the new and old certificates. Existing Defenders, however, must be redeployed to get the new certificates. Existing Defenders use the old certificates until they expire. Thereafter, these Defenders won’t be able to establish a connection to Console until they’re redeployed.
Single Defenders upgraded from the Console UI don’t get newly rotated certificates. To set up single Defenders with the new certificate, you must manually redeploy them.
To identify which Defenders require redployment, go to
Manage > Defenders > Manage > Defenders. Using the
Statuscolumn, you will be able identify the Defenders that are using an old certificate. Use the note at the top of the page to understand how many Defenders require redeployment, and when the old certificate will expire.
Using old certificatefilter on the Defenders list to see only the Defenders that are using an old certificate:
If you still have Defenders in your environment that are using an old certificate, which is about to expire in 60 days or less, you will get notified once entering the Console UI:
If the old certificate has expired, and you still have Defenders in your environment that are using the expired certificate, you will get notified once entering the Console UI. The
Statuscolumn on the Defenders page will reflect the Defenders that are using an expired certificate. Use the
Certificate expiredfilter on the Defenders list to see only the Defenders with expired certificate.
Additional technical details
This section provides additional technical details about how the certs that secure Console-Defender communication are managed.
What is the rotation model?
When Console is first deployed, it generates a set of certs for Console-Defender communication - a Defender CA, a Defender server cert, and a Defender client cert (with keys). The certs are valid for three years. Console initiates the certificate rotation. Console rotates the certs 1.5 years before the Defender CA expires. Thereafter, Console holds two sets of certificates: old and new Console rotates the new certs 1.5 years before the new Defender CA expires. The old certs are deleted, the new certs become the old certs, and a new set of certs are created.
Newly deployed Defenders, after rotation, are deployed with two sets of certs: old and new. Defenders that aren’t redeployed only have the old client certs and CA, and keep using them until they expire.
Until the old Defender CA expires, Console responds with the old Defender certs during the TLS handshake when Defender tries to connect to Console. As long as the old Defender CA is valid, Defender uses the old client cert for TLS handshakes. When the old certs expire, Defender uses the new certs for TLS handshakes.
Which certificates are rotated?
Console rotates the following files:
Are all certs rotated at the same time?
Yes, the Defender CA cert, server cert, and client cert are all rotated at the same time.
What triggers Console to regenerate and rotate the certs?
Console checks the expiration date of the Defender CA, and rotates all certs 1.5 years before the Defender CA expires.
What is the rotation frequency?
Once every 1.5 years.
What happens when you upgrade Prisma Cloud Compute?
When Console or Defenders are upgraded, the old, unexpired certificates remain on the system. Defenders that only have the old certificates are supported until the old Defender CA expires.
How can you programmatically determine that certs have been rotated?
Look for changes to the Defender certificates on the machine that runs Console. Certificates are stored in /var/lib/twistlock/certificates.
Inspect the Defender CA cert for its expiration time. When the .old suffix is added to the cert file, you will know it has been rotated.
Can you manage the certificate lifecycle yourself?
Yes, for Compute Edition (self-hosted) only. See Configure custom certs from a predefined directory.
SaaS Defenders connect to Console using an API token, not certs.
After certs have been rotated, what’s returned from api/v<VERSION>/defenders/daemonset.yaml?
The DaemonSet yaml will include both sets of new and old certs:
Which Defender types support certificate rotation?
Supported Defender types:
Serverless Defenders aren’t supported. Serverless Defenders are always deployed with old, unexpired certs, even if new certs exist.
What happens the moment a Defender’s old certs expire?
Defenders can switch to new certificates from old certificates at runtime. No restart is required.
Admission control certificates
Prisma Cloud provides a dynamic admission controller for Kubernetes that is built on the Open Policy Agent (OPA). The admission control certificate is used for the authentication between the Defenders and the admission webhook. When deploying the admission webhook, make sure it is configured with the right CA bundle, according to the Defender’s admission certificate. See the webhook configuration section on the admission control article.
Recommended For You
Recommended videos not found.