Prisma Cloud Compute Edition Administrator’s Guide
    : Best practices for DNS and certificate management
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Deployment patterns
    6. Best practices for DNS and certificate management
    Download PDF

    Prisma Cloud Compute Edition Administrator’s Guide

    Best practices for DNS and certificate management

    Table of Contents

    Best practices for DNS and certificate management

    As with most cloud-native software, Prisma Cloud relies on core infrastructure services, such as x509 cryptography and DNS name resolution. Defenders use these services to find and securely connect back to Console, and administrators use them to connect to Console and the API endpoints. When Console’s name can’t be resolved, or its certificate doesn’t include the name that Defenders use to connect to it, set up might fail and/or Defenders might not be able to successfully connect to Console.
    In relatively simple environments, such as an on-premises environment with a flat network, Prisma Cloud can automatically discover and configure the appropriate network configuration during setup. However, in more complex environments, auto-discovery is difficult and administrators typically have to manually configure the appropriate settings.
    Consider a deployment where Console exists in one cloud service, but protects hosts distributed across other cloud services in different regions. In this model, Console’s hostname is probably not resolvable by remote Defenders. And since Defenders probably do not connect directly to Console, but through some reverse NAT or a load balancer, the details of the underlying connectivity are probably obscured.

    Map out your topology

    Mapping out your topology is a fairly obvious step that is often overlooked, but it is the single best way to avoid connectivity problems.
    First, document Console’s local hostname and IP. Try to determine whether this name is the actual name that Defenders will use to connect, or if there is an another entity in between, such as a load balancer or reverse NAT service.
    Then, map out all the potential connection paths from Defenders to Console. For example, there might be some Defenders deployed in the same cloud service as Console. They can connect to Console directly. Other Defenders might connect from another routed network or over the Internet using different names.
    Documenting all of these paths and names at the beginning of the planning process saves significant time later when you’re troubleshooting. Use the following sample worksheet as a starting point:
    Console IP address:
Console local host name:
Console management port:
Console / Defender communication port:
    Load balancer / NAT IP address Load balancer / NAT name:
Load balancer / NAT management port:
Load balancer / NAT Console / Defender communication port:
    Defender to Console connection paths:
  Direct?
  From other cloud services in same deployment?
  Over the Internet?
    Because naming is so critical to connectivity, you should use durable, Prisma Cloud-specific names for accessing Console. For example, although the default host name might be ip-10-1-27-12, it would be a poor choice because it’s tied to a specific hostname, which could change if you redeploy Console to a new host.
    Instead, create a CNAME with a short TTL to reference this hostname, and use the CNAME for all name resolution. This way, if your hostname changes in the future, you simply need to remap the CNAME to the new hostname. Using CNAMEs is preferable to directly mapping an A record because many cloud services automate DNS resolution within their fabric and offer limited options for overriding this behavior. In a complex, multi-network environment, the CNAME can be used to reference Console both from the local network and from other networks, including the Internet, through simple and well established DNS configurations.
    Consider the following example scenario:
    • Console runs in cloud network 1, with an IP of 10.1.27.12, and local hostname of ip-10-1-27-12.
    • This IP can be accessed over the Internet through a load balancer.
    • The load balancer’s IP is 100.4.1.8, with a name of lb1.cloudprovider.com.
    • Some Defenders also run in cloud network 1.
    • Other Defenders run in a data center in another region, and connect to Console over the Internet.
    In this scenario, a good approach would be to create a CNAME, such as console.customer.com. Internet facing DNS servers would answer queries for Console with lb1.cloudprovider.com. Internal facing DNS servers would answer queries for Console with ip-10-1-27-12.

    Implement the topology

    After your naming scheme has been planned, the final step is implementing the names in Prisma Cloud.
    When you deploy a Defender, you must specify how it connects to Console, with either an IP address or, preferably, a DNS name. The Prisma Cloud dashboard lets you specify these names, and provides some preconfigured names, in the
    Subject Alternative Names
     table on the
    Manage > Defenders > Deploy
     page. Any name in the table is added to Console’s certificate and becomes available as a configuration parameter in the Defender deployment pages.
    Using our example scenario described in the previous section, the Subject Alternative Name table should contain the CNAME we chose (console.customer.com). If you have multiple names that you want to use to address Console, add them to the Subject Alternative Name table. For example, if Defenders in the same cloud network should access Console using cs1-console, you should have the following entries:
    • console.customer.com
    • cs1-console
    After Prisma Cloud is set up with these values, you will see them in the drop down menu in all of the Defender deployment pages as a configuration parameter. When you set up a new Defender, select how it should connect to Console from the same list of names in the Subject Alternative Names table.
    When you’re installing Defender, always ensure that the name you select from the drop down list can be resolved from the host where Defender will run. Using our example scenario, this means that you would select cs1-console for 'local' hosts that run in the same cloud service as the Console, and that you would select console.customer.com for 'remote' hosts. If the name you select cannot be resolved from the host where you install Defender, Defender set up will fail.

    Updating the list of resolvable names for Console

    Define additional names Defenders can use to connect to Console. After adding a name to the Subject Alternative Name table, the name is added to Console’s certificate and it is available in the drop down list in the Defender deployment pages.
    The values for CONSOLE_CN and DEFENDER_CN in twistlock.cfg should never be modified unless you are directed to do so by Prisma Cloud Support. These values are needed to work around distribution-specific abnormalities in the hostname command, which we use to create certificates during set up. Your custom names should always go in the Subject Alternative Name table, and never be hard-coded into CONSOLE_CN or DEFENDER_CN.
    1. In Console, go to
      Manage > Defenders > Deploy
      .
    2. In the
      Subject Alternative Name
       table, click
      Add row
      .
    3. Specify an IP address or fully qualified domain name.
    4. Redeploy any Defenders that require the new name to connect to Console.
      If the old names are still accessible, this step can be skipped.

    Recommended For You

    © 2023 Palo Alto Networks, Inc. All rights reserved.