Amazon Web Services (AWS) Credentials
Table of Contents
Amazon Web Services (AWS) Credentials
Prisma Cloud lets you authenticate with AWS using the following credentials.
- IAM users using access keys.
- IAM roles.
- Security Token Service (STS): Recommended when using IAM users.
AWS IAM users
In AWS, an IAM user is an identity that represents a person or service.
You create IAM users to allow that person or service 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.
IAM users must use both the access key ID and secret access key together to authenticate requests with AWS.
The Prisma Cloud credentials store can save the access keys of your IAM users.
To create a new credential in the store complete these steps.
. Select the
AWS
type and Access Key
subtype.
. Enter the access key ID and the secret access key.
The AWS best practice is to rotate your keys every 90 days. Prisma Cloud raises an alert if the added credentials are over 90 days old.
If you use IAM users, rotate your keys at least every 90 days.
AWS IAM roles
If you need to use temporary security credentials, you should use IAM roles instead of IAM users.
IAM roles and IAM users are identities associated to permission policies.
A permission policy determines what an identity can and cannot do in AWS.
IAM roles don’t use access keys as credentials and are not unique to a person or service.
Any IAM user can assume a role when needed to temporarily acquire the permissions 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:
- Create an IAM role.
- Specify the AWS service (e.g. EC2) that can assume the role.
- Specify the API actions and resources Prisma Cloud can use after assuming the role.
- Specify the role when you launch the service.
- 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 hassts:AssumeRolepermission 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).
