Secrets manager
Table of Contents
Prisma Cloud Enterprise Edition
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
- Deploy Defender with Declarative Object Management
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Configure Agentless Scanning for AWS
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and Restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Customize terminal output
- Collections
- Tags
- WildFire Settings
- Log Scrubbing
- Permissions by feature
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan Images in Alibaba Cloud Container Registry
- Scan Images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan Images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan Images in Google Container Registry (GCR)
- Scan Images in Harbor Registry
- Scan Images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger Registry Scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Malware Scanning
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert Mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
Secrets manager
Containers often require sensitive information, such as passwords, SSH keys, encryption keys, and so on.
You can integrate Prisma Cloud with many common secrets management platforms to securely distribute secrets from those stores to the containers that need them.
Enterprise secret stores reduce the risk of data breaches that could occur when sensitive information is littered across an organization, often in places where they should not be, such as email inboxes, source code repositories, developer workstations, and Dropbox.
Secret stores provide a central and secure location for managing and distributing secrets to the apps that need them.
They give you a way to account for all the secrets in your organization with audit trails that show how they are being used.
Orchestrators such as kubernetes and openshift, offer their own built-in secret stores with support for creating secrets, listing them, deleting them, and injecting them into containers.
However, if you already have an enterprise secrets store, then you probably want to extend it to handle to your container environment.
Utilizing the orchestrator’s built-in secrets management capabilities when you already have an enterprise secrets store is unappealing because it represents another silo of sensitive information that needs to be carefully secured.
It undermines the principal benefit of a secrets store, which is managing all sensitive data in a single location.
Theory of operation
When a user or orchestrator starts a container, Defender injects the secrets you specify into the container.
In order for secret injection to work, all Docker commands must be routed through Defender, so be sure to download your client certs and setup your environment variables under
Manage > Authentication > User Certificates
.There are several moving parts in the solution:

A
.
Secret values are fetched, encrypted, and stored in Console’s database when a rule is created or modified.
Secret values in Console’s database are periodically synced with the secrets store to provide resiliency in the case of connectivity outages and to optimize performance. All secrets cached on disk, both in Defender and in Console, are protected with 256 bit AES encryption.
If you change a secret’s value in the secrets store and you need it synced immediately, you can click the refresh button in the Console UI to refetch all secrets from their configured stores.1
.
Operator (or orchestrator) starts a container with docker run.2
.
Defender assesses the command against the policy installed in Console.3
.The secret is returned to Defender.
Defender starts the container using the Docker API, which is exposed through the Docker daemon’s local UNIX socket, and injects the secret into the container.Capabilities
The Prisma Cloud secrets manager has the following capabilities:
- Supports integration with common secrets management platforms.
- Manages the distribution of secrets from the secret store to your containers through policies. In Console, you create the rules that control which secrets get injected into which containers.
- Injects secrets into containers as either environment variables or files.
- Secrets injected as environment variables are presented in-the-clear from within the container. They are redacted from the outside to prevent exposure by the docker inspect command.
- Secrets injected as files are provided from an in-memory filesystem (on /run/secrets/<SECRET_NAME>) that is mounted into the container when it is created. When the container is stopped, the secrets directory is unmounted and deleted.
Best practices
There are a number of ways that secrets can be compromised.
Defender is bypassed.
If Defender is bypassed, an attacker can execute Docker commands directly against the Docker daemon’s local UNIX socket, and he will be able to expose your secrets.
Be sure that your hosts are secured with least privilege access so that users can only run docker commands through Defender.
Limit lower privileged users to monitoring commands, such as docker ps and docker inspect.
Prisma Cloud automatically encrypts secrets injected as environment variables when accessed from docker inspect.
Restrict commands such as docker exec and docker run to just the operators that need them because these commands can reveal secrets injected into a container by giving the user shell access inside the container, where variables are in the clear.
For example, docker exec printenv on a running container, or docker run <IMAGE_ID> printenv on an image, can reveal environment variables that are otherwise encrypted with docker inspect.
The following diagram shows one way to grant access to Docker functions based on a user’s role.
This is the way that Docker Datacenter Universal Control Plane (UCP) grants permissions, and you can implement the same scheme with Prisma Cloud’s access control rules.