Skip to content

Twistlock / Prisma Cloud Compute

Twistlock is the former name for Prisma Cloud Compute. In Big Bang, this package provides the Prisma Cloud Compute Console and, in its default deployment mode, an initialization Job that configures the Console and can install Kubernetes Defenders. Use the Prisma Cloud Compute documentation for product administration, policy design, Defender behavior, and upgrade instructions.

Big Bang integration

Enable the package with the umbrella’s packages.twistlock configuration. The umbrella deploys the package into the twistlock namespace and supplies Big-Bang-wide settings such as the selected ingress gateway, image pull secret, monitoring integration, and dependencies on enabled policy, mesh, and monitoring packages. The package’s complete configuration surface is documented in its values.yaml; use the parent twistlock.values for package values passed through by the umbrella rather than copying upstream configuration into umbrella values. This follows the Big Bang upstream-values documentation policy.

The ordinary deployment renders a single Console with a persistent volume. Size, access mode, storage class, backup, and recovery planning remain operator responsibilities; consult the Prisma Cloud Console deployment guidance.

Console and Defender deployment boundaries

With deploymentMode.defenderOnly: false (the default), the package deploys the Console and initialization Job. When initialization is enabled, it uses the Console API to set up the configured administrator, apply a configured license, and—when defender.enabled is true—obtain and deploy the Defender DaemonSet. Defender installation is therefore not a manual prerequisite for this path.

deploymentMode.defenderOnly: true is for connecting a cluster to a Console managed elsewhere. It does not deploy a Console or initialization Job. Operators must provide the target Console connection details and Defender certificate material before installing it; see Defender-only mode.

Defenders are node-level security workloads. They use host networking and host paths and may require privileged capabilities and cluster permissions. Review cluster admission and security-policy requirements before enabling them. In ambient mesh mode, the package labels Defender pods to exclude them from ambient capture.

Credentials, licensing, and SSO

The initialization Job requires console.credentials when it is enabled. A license can be supplied through console.license for initialization, or installed through the supported Console workflow. Do not commit administrator credentials, license data, client secrets, or certificates in plaintext values files.

For SAML and OIDC, use the package’s pre-created Secret support for sensitive material (sso.existingSecret and oidc.existingSecret) and manage those Secrets through the deployment’s approved encrypted-secret process. See OIDC SSO integration and SAML/Keycloak integration. For identity-provider and Console configuration details, use the Prisma Cloud authentication documentation.

Networking, ingress, and mesh

When Istio integration is enabled, the package uses the configured bb-common inbound route to expose the Console through the selected gateway. This route is for the Console; it is not a Defender-installation mechanism. The Console, Defenders, initialization Job, monitoring, and external integrations must all remain reachable under the deployment’s NetworkPolicy and mesh egress policy.

For OIDC behind an ingress gateway that terminates TLS, enable console.backendTLS so the gateway-to-Console connection uses the Console HTTPS port. The chart creates the necessary DestinationRule and excludes that inbound port from sidecar interception. Configure any required external identity-provider or product endpoints using the package’s bb-common egress configuration; do not use broad egress exceptions as a substitute for reviewing required destinations.

Granting Egress to Blocked Services

Console-configured integrations, including an external identity provider or notification endpoint, may also require network and mesh configuration. A successful UI configuration does not grant connectivity. The chart already registers intelligence.twistlock.com through its default outbound route; do not replace or remove that route when adding another destination.

In sidecar mode, traffic captured by a proxy with effective REGISTRY_ONLY policy can be denied if its destination is unregistered. The chart exposes istio.sidecar.outboundTrafficPolicyMode; rendering a Sidecar does not inject a proxy. Check namespace enrollment, actual injection, and capture exceptions. Defenders use host networking and are excluded from ambient capture, so a Console-pod proxy check does not diagnose every Defender connection failure.

Discovering Blocked Hosts

Confirm the intended kubeconfig and list Console pods using the chart’s default label, adjusting it if the Console name was overridden:

kubectl -n twistlock get pods -l app.kubernetes.io/name=twistlock-console --show-labels

Select a Console pod and inspect its regular and init containers. In Defender-only mode the Console is remote; perform these checks at its owning deployment instead:

SOURCE_POD="replace-with-console-pod-name"
kubectl -n twistlock get pod "$SOURCE_POD" \
  -o jsonpath='{.spec.containers[*].name}{"\n"}{.spec.initContainers[*].name}{"\n"}'

If it has an istio-proxy, inspect recent proxy logs during the failed integration request:

kubectl -n twistlock logs "$SOURCE_POD" -c istio-proxy --since=10m \
  | grep -i 'BlackHoleCluster'

With proxy access logging enabled, BlackHoleCluster entries can help identify unregistered destinations. No match does not prove connectivity: check Console errors, DNS, NetworkPolicies, TLS trust, and remote credentials too. In ambient mode, inspect the relevant ztunnel/waypoint path rather than assuming a pod proxy; see the umbrella’s ambient guidance. Redact tokens, license information, and sensitive request metadata before sharing logs.

Registering External Destinations

These umbrella values add one HTTPS integration destination through the supported custom ServiceEntry interface. Replace the host with the actual integration endpoint; keep any existing entries that remain required:

packageConfiguration:
  version: v1
packages:
  twistlock:
    values:
      bb-common:
        istio:
          serviceEntries:
            custom:
              - name: console-integration
                spec:
                  hosts:
                    - integration.example.com
                  exportTo: ["."]
                  location: MESH_EXTERNAL
                  resolution: DNS
                  ports:
                    - number: 443
                      name: https
                      protocol: TLS

The mesh and its APIs must already be available; this does not enable injection or configure the Console integration. Legacy values use twistlock.values.istio; direct chart values start at istio. The custom array replaces existing custom entries, but leaves the separate routes.outbound defaults intact. Use these current interfaces rather than the old istio.hardened.customServiceEntries path.

Mesh registration does not grant destination IP/port access through enabled NetworkPolicies. Review the Console’s networkPolicies.egress rules, DNS access, and endpoint IP behavior separately; use the actual source workload for init or Defender traffic. Do not switch to ALLOW_ANY or broad internet egress as a routine fix. Commit narrow changes through GitOps, then verify the intended integration against a disposable target without changing enforcement policies.

See the bundled bb-common 1.6.0 Istio and NetworkPolicy guides; match the version to Chart.yaml.

Monitoring

Set monitoring.enabled only when the Big Bang monitoring integration and the initialization Job are available. The initialization path creates the Console metrics user and configures the chart’s ServiceMonitor and network access. See Monitoring and the Prisma Cloud Prometheus integration documentation.

Operations and support

The initialization Job can configure supported users, policies, trusted images, logging, and Defender setup, but it is not a replacement for Prisma Cloud operational procedures. Use Initialization for the package-managed scope and Troubleshooting for the package troubleshooting entry point. Follow the version-appropriate Prisma Cloud release and administration documentation before product upgrades or policy changes.