Credentials store

Container environments tend to utilize many third party services across multiple cloud providers. To improve accessibility and reusability, Prisma Cloud manages all credentials in a central encrypted store. Credentials are used when setting up the following integrations:
  • Scanning (container registries, serverless functions, etc).
  • Alerting in third party services (email, Slack, ServiceNow, etc).
  • Deploying and managing Defender DaemonSets from the Console UI.
  • Injecting secrets from secret stores into containers at runtime.
The credential store can be found under
Manage > Authentication > Credentials Store
. Credentials cannot be deleted if they are currently in use. To see all the places where a credentials is being used, click on an entry in the credentials store table, and review the
Usages
list.
If a credential is being used by an integration, and you edit its parameters (e.g. username, password, etc), the new values are automatically propagated to the right places in the product. You don’t need to delete and set up the integration again to refresh a credential’s values.

Prisma Cloud Onboarded accounts

When you start with a fresh Prisma Cloud tenant, you can use the guided onboarding flow to automatically create service accounts and roles in your cloud provider accounts so that Prisma Cloud can be quickly integrated with your cloud providers.
The guided onboarding flow creates service accounts and roles for the following Compute-specific integrations. For all other integrations, manually create the required service accounts or roles according to the feature-wise permissions doc.
Feature
AWS
Azure
GCP
Cloud discovery
Yes
No
No
Cloud compliance
Yes
N/A
1
N/A
1
Serverless Radar
Yes
N/A
1
N/A
1
Registry Scanning
Yes
No
No
Serverless scanning
Yes
No
No
Serverless auto-protect
Yes
N/A
1
N/A
1
VM image scanning
Yes
N/A
1
N/A
1
Kubernetes auditing
No
2
No
2
No
Alerting — AWS SecurityHub
Alerting — GCP SecurityCenter
Alerting — Google Cloud Pub/Sub
Secret stores — Azure Key Vault
Secret stores — AWS Secret Manager
Secret stores — AWS System Manager Parameter Store
1
N/A means the feature isn’t supported in the product for this cloud provider. For this reason, no service account or role needs to be created.
2
Kubernetes auditing is supported for all self-managed clusters, regardless of the cloud provider. For managed clusters, GKE is supported.
For Azure container registry scan feature and Cloud Discovery feature, the onboarded credentials from Prisma Cloud will not work because of the authentication method that Azure requires. Using a shared token based method (as part of onboarded accounts) is not supported. Direct credentials will need to be added in Compute for these features.

Prisma Cloud AWS accounts

Compute feature specific minimalistic permissions are added by default to all CloudFormation Templates for AWS accounts onboarded to Prisma Cloud. These permissions are defined by the following two roles.
You can remove these roles from the CFTs if you do not wish to use onboarded cloud accounts for Compute capabilities.
PrismaCloud-ReadOnly-Policy-Compute
  • ecr:BatchCheckLayerAvailability
  • ecr:BatchGetImage
  • ecr:DescribeImageScanFindings
  • ecr:GetAuthorizationToken
  • ecr:GetDownloadUrlForLayer
  • ecr:GetLifecyclePolicyPreview
  • ecr:ListImages
  • kms:Decrypt
  • lambda:GetFunction
PrismaCloud-Remediation-Policy-Compute
  • ec2:AuthorizeSecurityGroupEgress
  • ec2:AuthorizeSecurityGroupIngress
  • ec2:CreateSecurityGroup
  • ec2:CreateTags
  • lambda:GetLayerVersion
  • lambda:PublishLayerVersion
  • lambda:UpdateFunctionConfiguration
  • ssm:CreateAssociation
Some additional permissions required for Compute features like AMI scanning are missing from these templates in order to keep minimalist privileges. You can find full list of feature wise AWS permissions here: http://cdn.twistlock.com/docs/downloads/Compute-Feature-Wise-Permissions-Hamilton.pdf and add them manually.

Cloud Account Permission Status

CFTs will be updated with Compute permissions on platform level on tentatively Oct 7th for all accounts but the status check on those permissions for Compute will NOT be done by default. Currently cloud account status checks do not take Compute permissions into account. They will remain green even if Compute permissions are missing in order to accomodate for the CSPM users who do not use Compute functionalities and thus change in account status could cause confusions.

Prisma Cloud Azure accounts

No additional permissions are added for Compute by default to the onboarding templates. You can add the following permissions for Serverless and Cloud Discovery scans.
"Microsoft.Web/sites/publishxml/action", "Microsoft.Web/sites/Read", "Microsoft.Web/sites/config/Read", "Microsoft.Web/sites/functions/read", "Microsoft.Web/sites/config/list/action", "Microsoft.ContainerRegistry/registries/read", "Microsoft.ContainerRegistry/registries/metadata/read",
"Microsoft.ContainerService/managedClusters/read", "Microsoft.ContainerInstance/containerGroups/read

Prisma Cloud GCP accounts

No additional permissions are added for Compute to the onboarding templates. You can find full list of GCP permissions below and add them manually.
For projects:
"storage.objects.get", "storage.objects.list", "pubsub.topics.publish", "iam.serviceAccounts.get", "iam.serviceAccounts.getAccessToken", "iam.serviceAccounts.getOpenIdToken", "iam.serviceAccounts.implicitDelegation", "iam.serviceAccounts.list", "iam.serviceAccounts.signBlob", "iam.serviceAccounts.signJwt"
For ORG:
"resourcemanager.projects.get", "resourcemanager.projects.list"

Using onboarded accounts

The service accounts and roles required for integrating Prisma Cloud with your cloud provider can be automatically created in your cloud account for you. Initiate the onboarding process from
Settings > Cloud Accounts
.
After onboarding an account, you can use the service accounts and roles, collectively called credentials, when configuring Compute. Before using a credential, however, you must first "surface" the credential in Compute.
Surfaced credentials are read-only in the Compute tab. Update them at the source in
Settings > Cloud Accounts
.
Similarly, deleting surfaced credentials in the Compute tab’s credentials store only removes them from the table. Delete them at the source in
Settings > Cloud Accounts
.
  1. After logging into Prisma Cloud, go to to the
    Compute > Defend > Authentication
    tab.
  2. Click
    Add Credential
    .
  3. In
    Type
    , select
    Prisma Cloud
    .
  4. Select all credentials you want to use.
  5. Click
    Save
    .
  6. You can now use the credential in Compute.
    For example, to set up registry scanning for AWS ECR:
    1. Go to
      Compute > Defend > Vulnerabilities
      .
    2. Go to
      Images > Registry Settings
      , and click
      Add Registry
      .
    3. When you’re setting up the integration, select the surfaced credential is available for use.

AWS

Prisma Cloud lets you authenticate with AWS the following ways:
  • IAM users (access keys).
  • IAM roles.
  • Security Token Service (STS) (Recommended when using IAM users).

AWS IAM users

An IAM user is an identity that you create in AWS. It represents a person or service that uses the IAM user to interact with AWS.
Access keys are long-term credentials for IAM users. Access keys consist of two parts: an access key ID and a secret access key. Like a username and password, you must use both the access key ID and secret access key together to authenticate requests with AWS.
The credentials store in Prisma Cloud lets you save access keys. When creating a new credential, select the
AWS
type and
Access Key
subtype, and then enter an access key ID and secret access key.
NOTE
As per AWS best practices, it is recommended to rotate your keys every 90 days. Prisma Cloud will raise an Alert if the age of the credentials added is >90 days. Ensure that if you use this option, rotate your keys at least every 90 days.

AWS IAM roles

In many cases, you can take advantage of IAM roles and their temporary security credentials rather than the long-term credentials associated with IAM users.
IAM roles are similar to IAM users. Both are identities with permission policies. The permission policy determines what an identity can (and cannot) do in AWS. However, roles don’t have any associated credentials (e.g. access keys). Instead of being uniquely associated with one person, roles are assumable by anyone who needs them. IAM users can assume a role to temporarily acquire the permissions needed to carry out a specific task.
IAM roles solve the problem of how to securely manage and distribute credentials. For example, how do you distribute credentials to new EC2 instances created by an auto scaling group? How do you rotate credentials on EC2 instances in a cluster? Instead of creating and distributing credentials, you can delegate permission to call the AWS API as follows:
  1. Create an IAM role.
  2. Specify the AWS service (e.g. EC2) that can assume the role.
  3. Specify the API actions and resources Prisma Cloud can use after assuming the role.
  4. Specify the role when you launch the service.
  5. Prisma Cloud retrieves a set of temporary credentials and uses them as needed.
Prisma Cloud ships with a default credential called
IAM Role
. Assuming you’ve created an IAM role in AWS, configured trust (who can use the role), permission policy (what the role can do), and launched the service with the role, Prisma Cloud can acquire the temporary credentials it needs to carry out its work. Each feature in Prisma Cloud has documentation which describes permission policy it requires.

How Prisma Cloud accesses IAM role credentials

Roles provide a way to grant credentials to applications that run on EC2 instances to access other AWS services, such as ECR. IAM dynamically provides temporary credentials to the EC2 instances, and these credentials are automatically rotated for you.
This section shows how Prisma Cloud Defender gets credentials to scan the ECR registry when its running on an EC2 instance with a correctly configured IAM role. The mechanism is similar for other services where Prisma Cloud might run.
When you create an EC2 instance, you can assign it a role. When the instance is started, the AWS instance metadata service (IMDS) attaches your credentials to the running EC2 instance. You can access this metadata from within the instance using the following command:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<POLICY_NAME> { "Code" : "Success", "LastUpdated" : "2017-06-29T06:12:29Z", "Type" : "AWS-HMAC", "AccessKeyId" : "ASIA...", "SecretAccessKey" : "3VI...", "Token" : "dzE...", "Expiration" : "2017-06-29T12:16:54Z" }
Where <POLICY_NAME> is assigned to the EC2 instance when it is created or at some point during its life.
The following diagram shows all the pieces. Defender retrieves the credentials from the metadata service, then uses those credentials to retrieve and scan the container images in ECR.

AWS Security Token Service (STS)

AWS Security Token Service (STS) lets you request temporary, limited-privilege credentials for AWS IAM users or users that you authenticate (federated users).
Per the AWS Well-Architected Framework, this method is a recommended best practice when using IAM users. With STS, you don’t have to distribute long-term AWS credentials (access keys) to places like the Prisma Cloud credentials store. Also, the temporary credentials have a limited life span, so you don’t have to rotate or revoke them when they’re no longer needed.
When you configure integration with an AWS resource, you can pick an AWS credential from the central store, then use STS to change the role of the account. AWS STS lets you have a few number of IAM identities that can be used across many AWS accounts. For example, if you were setting up Prisma Cloud to scan an AWS ECR registry, you would select the AWS credentials from the central store. Then you would enable
Use AWS STS
, and enter the name of the STS role to assume in the target account.
When using AWS STS, ensure the following:
  • The policy of the IAM user you use as credentials has
    sts:AssumeRole
    permission on the IAM role you’re going to assume. Sample policy:
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789123:role/stsIAMrole" } ] }
  • The IAM role you’re going to assume has the IAM user mentioned above configured as a trusted entity. Sample trusted entity policy:
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789123:user/prismaUser" }, "Action": "sts:AssumeRole" } ] }
The following diagram shows the relationship between an IAM user, a permissions policy, and an assumed role. By default, the IAM user has no permissions. The permissions policy allows ready-only access to the ECR registry. The role brings everything together. It specifies the trust relationship (who is allowed to assume the role, also known as the principal), it grants to ability for the principal to assume roles (sts:AssumeRole), and it declares what the role can do when it assumed by a principal (permission policy).

Azure

This section discusses Azure credentials.

Creating an Azure Service Principal

Create an Azure Service Principal so that Prisma Cloud Console can scan your Azure tenant for microservices. To get a service key:
  1. Download and install the Azure CLI.
  2. Create a service principal and configure its access to Azure resources.
    $ az ad sp create-for-rbac \ --name <user>-twistlock-azure-cloud-discovery-<contributor|reader> \ --role <reader|contributor> \ --sdk-auth
    The
    --role
    value depends upon the type of scanning:
    • contributor = Cloud Discovery + Azure Container Registry Scanning + Azure Function Apps Scanning
    • reader = Cloud Discovery + Azure Container Registry Scanning
  3. Copy the output of the command and set it aside. It will be used as the
    Service Key
    when creating an Azure credential.
    { "clientId": "bc968c1e-67g3-4ba5-8d05-f807abb54a57", "clientSecret": "5ce0f4ec-5291-42f8-gbe3-90bb3f42ba14", "subscriptionId": "ae01981e-e1bf-49ec-ad81-80rf157a944e", "tenantId": "d189c61b-6c27-41d3-9749-ca5c9cc4a622", "activeDirectoryEndpointUrl": "https://login.microsoftonline.com", "resourceManagerEndpointUrl": "https://management.azure.com/", "activeDirectoryGraphResourceId": "https://graph.windows.net/", "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/", "galleryEndpointUrl": "https://gallery.azure.com/", "managementEndpointUrl": "https://management.core.windows.net/" }

Storing the credential in Prisma Cloud

Store the service principal’s credentials in Console so that Prisma Cloud can authenticate with Azure for scanning.
  1. Open Console, and go to
    Manage > Authentication > Credentials Store
    .
  2. Click
    Add credential
    , and enter the following values:
    1. In the
      Name
      field, enter a label to identify the credential.
    2. In the
      Type
      field, select
      Azure
      .
    3. In the
      Service Key
      field, enter the value returned by the Azure CLI tool when you created the service principal.
    4. Click
      Save
      .

Google Cloud Platform (GCP)

Accessing GCP to scan resources can be done in one of two ways. You can make use of a service account and create a key for that account or you can use an API Key. Google recommends that you use a service account with a key and we document that here. More information is available here https://cloud.google.com/docs/authentication/api-keys

Creating a service account

Create a service account that Prisma Cloud can use to scan your resources in GCP.
  1. Google provide a comprehensive guide for creating a service account - https://cloud.google.com/iam/docs/creating-managing-service-accounts
  2. Create a key for this service account. The format of this key should be JSON. Google have a guide for this - https://cloud.google.com/iam/docs/creating-managing-service-account-keys
  3. Copy the contents of the downloaded key, here is an example:
    { "type": "service_account", "project_id": "mycompany-project", "private_key_id": "abe29475a09fb22e709fdc622306a714e17cqd1c", "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFBBSCBKgwggSkAgEAAoIBAQCyBJgPechqsXAK\nTaz1y77AGqei47IbgWegRq8JqqoQGERhBX8X41otaRNUIn7fpTdH/JjRfJ0wyduz\nn6TLmeMz+d/yIZBtztujJ4KoGTS0yTybtcKWKg254upri6RIcMS3ArNXsNtSwLQx\nicVDCI3uDKLuNyawmLf1BiHLwWZK8bOUe5thd3J9UXc+B+dL9JRYyz1Iq+X/Nz1w\n7D3TPXfy54Hg39rDRrx0bK0E+AIRMA5vPFmGrWlYn6HyltOxCU/D5NUrExRo3aug\nsIvQgGE3QYLU4a5n9jsWPbjSGI+EH/+zZ1fze5pk6rprlvKtbvygJSFGpdsjS4EX\nbFgPVYGJAgMBAAECggEABu9fIaY1yLNIKTyYrvwsnpUDQBkk/oWSbQfn6IVfqfAa\nFNoHFx4GLLP12u6bmPiZoFoutWWIhaatgpBG9iAU/fi/cNI+K0r2W0MuJ8CQoTTg\nQbQpZBp4Daxxg7ZNVH2hKjyGklVbW/xSIMZsWwXNqq8PF17qaNGQRBFEtoh+pM94\nJ23ZKIW5muF+5Svz4wLLS7VMtbl/XrM9eCepVQNzQ701A67VQa1Z8KIot5IeQ0d2\njnHJn6XgaDe/IKuP8ClXnCUwo/GbChCtctP0BpTeaTSOUrc1O7ntgFBGYxiSmgZ0\n13x43XkuYaycyZEycKEOaa9U+k1KrcFZ/CDQdv+AUQKBgQD25mVWFxQdhFqF12vu\nEhz0jRjLbre+V3UgOYJObmKMdM6iH+NQ9CNeFIn8qgHgOK7pHEgjcLvAv4ZgECin\n1XtMNAFGRREGuzovvzQKwBGAEz8PovI2gkITqmcSQ7xzcGyY1Xm1mthpqkoWFe5c\nk253fYhMjuITTXisYv8LBl5XGQKBgQC4lER2AmTSvLe+4sulTeDEocMsP+G4j/A1\neS1mG5e5YGUtuWgIdfNKUn1YG5uX3ERZVeCdRO7B/osQ4uAeJ1SIS3Zvw5QVtS/s\nFOJa1UJ/nxGAA8vApjRgJkLyRbf/yoxsRlCQkQJcRd1SO9DRlCSWdSW1CpIpauiN\nfZZW3iD78QKBgQCWW7Lk3cMjQqH6FjmlTySRDYhHA1MkuI1fFga0Cuc7EDtyYicF\n+te7CJkL5OClkv95+P45jwLYHAsSX2TDE3o16wnHqHH4/nYt86wWy+ccbxwdQqds\n6KCi50hDyDpwtst7u62WGgmnN8xMbOivOh2w6SLjNyQ0ix5tJRCavzMeqQKBgQCu\nYvajf/N93urDIEdC8Gcxn5tkTR6XXvaVrt0joWIhtF8jag5OIBIx3+m55rywJ100\nAhzquVvSUQlWdONF2ebVtmY5hdB9Cegy5jBNnTrslH7WMb/pTZ4iUUPi3dfPhbBS\nA8TOMRLH1wIZVYYe3BYNSLTNbSVWmDkKpOLLQ6ZqIQKBgA0rkqfzz0MIij58OugB\nFyv8UWvy+hYR15EvIFOl5jXomVl199x+XHQGiwV6cXGmGcii7eC7vXSmnjxILMEA\nD4Odwi9vmyJXOtIT1WlVj/faLrpKfunZEphYnrtRASuDzzU4cTbeElhfLOqkJEA4\nK4CCBhjL3UX8Z9FbJJz7mYoX\n-----END PRIVATE KEY-----\n", "client_email": "mycompany-service-svc@mycompany-project.iam.gserviceaccount.com", "client_id": "120957099362691824155", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/mycompany-service-svc%40mycompany-project.iam.gserviceaccount.com" }

Storing the credential in Prisma Cloud

Store your GCP credential in Prisma Cloud.
  1. Open Console, and go to
    Manage > Authentication > Credentials Store
    .
  2. Click
    Add credential
    , and enter the following values:
    1. In the
      Name
      field, enter a label to identify the credential.
    2. In the
      Type
      field, select
      GCP
      .
    3. In the
      Service Account
      field, copy and paste the entire JSON key that you downloaded.
    4. Leave the
      API token
      blank
    5. Click
      Save
      .

IBM Cloud

Prisma Cloud integrates with IBM Cloud Security Advisor. To enable the integration, you must provide credentials, which consist of an Account GUID and API Key.

Kubeconfig

Kubernetes stores cluster authentication information in a YAML file known as kubeconfig. The kubeconfig file grants access to clients, such as kubectl, to run commands against the cluster. By default, kubeconfig is stored in $HOME/.kube/config.
Prisma Cloud uses the kubeconfig credential to deploy and upgrade Defender DaemonSets directly from the Console UI. If you plan to manage DaemonSets from the command line with kubectl, you don’t need to create this type of credential.
The user or service account in your kubeconfig must have permissions to create and delete the following resources:
  • ClusterRole
  • ClusterRoleBinding
  • DaemonSet
  • Secret
  • ServiceAccount
Prisma Cloud doesn’t currently support kubeconfig credentials for Google Kubernetes Engine (GKE) or AWS Elastic Kubernetes Service(EKS). The kubeconfig for these clusters require an external binary for authentication (specifically the Google Cloud SDK and aws-iam-authenticator, respectively), and Prisma Cloud Console doesn’t ship with these binaries.
  1. Open Console, and go to
    Manage > Authentication > Credentials Store
    .
  2. Click
    Add credential
    , and enter the following values:
    1. In
      Name
      , enter a label to identify the credential.
    2. In
      Type
      , select
      Kubeconfig
      .
    3. In
      Kubeconfig
      , paste the contents of your kubeconfig file.

Recommended For You