Inject secrets into containers
Table of Contents
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Prisma Cloud Container Images
- Kubernetes
- Deploy the Prisma Cloud Console on Amazon ECS
- Console on Fargate
- Onebox
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Container Service (ACS) with Kubernetes
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- IBM Kubernetes Service (IKS)
- OpenShift v4
-
- 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
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- 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
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
-
- 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
- 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
Inject secrets into containers
To inject secrets into your containers, first integrate Prisma Cloud with your secrets manager, and then set up rules for injecting specific secrets into specific containers.
Use the same procedure for injecting secrets in a Kubernetes cluster.
Set up your rules to target specific containers, images, or labels.
Make sure Kubernetes uses dockerd and Prisma Cloud is running in local socket mode.
Injecting secrets into containers
After integrating your secrets store with Prisma Cloud, specify which secrets should be injected into which containers.
To do this, create the appropriate rules in Console.
Secrets can be injected as environment variables or as files.
For secrets injected as environment variables: if there is a collision between a predefined environment variable and an injected secret, the value of the environment variable will always be the value of the secret.
For security reasons, secrets injected as environment variables are only exposed to the container’s main process and children of the main process.
For secrets injected as files: they can be found in /run/secrets/<SECRET_NAME>, where the contents of the file contain the secret’s value.
By default, secrets can only be read by root users in the container space.
If you run your containers as non-root users, configure the injection rule to make the secrets readable by all users.
Prisma Cloud can set the access permissions of the injected secrets file to read-only for the 'others' class of users.
For more information about access permissions and 'others', see the chmod man page.
Secrets injection currently only works with image labels, not container or host labels.
Prerequisite:
You’ve already created a secret in your store or vault.- In Console, go toDefend > Access > Secrets.
- ClickAdd new secrets rule.
- Specify a name for your rule.
- Specify how your secret(s) should be injected. You can choose between environment variables and files.If you choose files, you can select how the files are injected into the container. By default, the files are readable by root users only. If your containers run as non-root users, selectAll Users. TheAll Usersoption makes the files readable by any user by setting read permission for the others class of users.
- Create a list of secrets from your store that you want to inject into your container(s). UnderAdd secret:
- Specify a secret name.When you inject secrets as environment variables, this field specifies the environment variable name.When you inject secrets as files, this field specifies the file name.
- Specify the store where the secret is stored. The drop-down list contains any store that you integrated with Prisma Cloud.
- Specify the secret’s path and key.
- ClickAdd Secret. It is added to the list of secrets.
- Repeat steps a through d for as many secrets that must be included in your rule.
- Specify a scope for your rule with one or more collections. By default, theAllcollection is selected, which injects all secrets into all containers on all hosts.
- ClickAdd.
- Verify that your secrets are properly injected.For example, assuming your rule targets the alpine container and secrets are injected as environment variables, run the following commands:Default rules target all resources in the environment. TheContainers,Images,Hosts, andLabelsfields are set to wildcards. If your rule is set up this way, then your secrets will be injected into the alpine container.$ docker run -it alpine:latest /bin/sh / # printenvIf your secrets are injected as files, and you leftTarget directoryunspecified in your rule, then your secrets are injected into /run/secrets/, where <SECRET-NAME> is the name of the injected file, as specified in your rule.$ docker run -it alpine:latest /bin/sh / # cat /run/secrets/<SECRET-NAME>