DEV Community: Alessandro Gaggia

Increase AWS Security Posture with IAM Roles and Policies

Alessandro Gaggia — Thu, 03 Aug 2023 12:00:00 +0000

In this article we will discuss identity and access management (IAM) within Amazon Web Services (AWS), focusing on the similarities and differences between IAM roles and policies.

This article will provide examples of both roles and policies and explains how they relate to IAM roles, users, and groups.

By the end, you will have a clear understanding of IAM within AWS and be better equipped to manage access and identity needs on the platform.

What is an IAM Policy in AWS?

An IAM policy is a document that defines permissions for AWS resources. It is an essential component of AWS identity and access management (IAM) that provides fine-grained control over who can access specific resources in your AWS account.

IAM policies are used to grant or deny access to AWS resources such as Amazon S3 buckets, EC2 instances, and RDS databases.

IAM policies are written in JSON format and consist of one or more statements. Each statement contains a set of permissions for a specific resource or set of resources. For example, you might use an IAM policy to grant read-only access to a particular S3 bucket, or to allow a user to start and stop an EC2 instance.

Elements of an IAM Policy

An IAM policy is comprised of the following main elements:

Element	Description
Version	The version of the IAM policy language used.
Statement	A list of one or more statements that define the permissions for the policy.
Effect	Specifies whether the statement allows or denies access to the resource.
Action	The specific actions that are allowed or denied for the resource.
Resource	The AWS resource that the policy applies to.
Principal	The entity that the policy applies to.

Version

The Version element specifies the version of the IAM policy language used in the policy.

The current version of the policy language is October 17, 2012.

Example:

{
    "Version": "2012-10-17",
    ...
}

Statement

The Statement element is a list of one or more statements that define the permissions for the policy.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            ...
        },
        {
            ...
        }
    ]
}

Effect

The Effect element specifies whether the statement allows or denies access to the resource.

The values for Effect are Allow and Deny.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            ...
        },
        {
            "Effect": "Deny",
            ...
        }
    ]
}

Action

The Action element specifies the specific actions that are allowed or denied for the resource.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            ...
        },
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            ...
        }
    ]
}

Resource

The Resource element specifies the AWS resource that the policy applies to.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/*",
            ...
        },
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "*",
            ...
        }
    ]
}

Principal

The Principal element specifies the entity that the policy applies to.

Example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/*",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123456789012:user/Bob",
                    "arn:aws:iam::123456789012:role/DevOps"
                ]
            },
            ...
        },
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "*",
            "Principal": "*",
            ...
        }
    ]
}

What is an IAM Role in AWS?

An IAM role is an AWS identity with permission policies that determine what the identity can and cannot do in AWS.

IAM roles are similar to IAM users, but with some important differences.

IAM roles are not associated with a specific user or group. Instead, they are intended to be assumed by anyone who needs the permissions associated with the role.

IAM roles are a way to delegate access to AWS resources without the need to create and manage long-term AWS credentials.

For example, you might create an IAM role that grants access to an S3 bucket, and then allow a Lambda function to assume that role when it needs to access the bucket.

This way, you don't need to manage access keys for the Lambda function, and you can maintain tighter control over who has access to the S3 bucket.

Main Elements of an IAM Role

Element	Description
Role Name	The name assigned to the role.
Role ARN	The Amazon Resource Name (ARN) assigned to the role.
Assume Role Policy	The policy document that grants permission to assume the role.
Inline Policies	One or more inline policies that are attached to the role.
Managed Policies	One or more managed policies that are attached to the role.

Assuming an AWS IAM Role

Assuming an AWS IAM Role means temporarily taking on the permissions and policies associated with that role. This is done by using the AWS Security Token Service (STS) API to obtain temporary security credentials, which include an access key, a secret access key, and a security token.

The user who is assuming the role must have permission to do so, which is granted by the role's trust policy. The trust policy specifies which users or services are allowed to assume the role.

There are several ways to assume an IAM Role in AWS, including using the AWS Management Console, AWS CLI, AWS SDKs, and the AssumeRole API.

When using the AssumeRole API, the user must provide their own security credentials and the ARN of the role they want to assume. The API then returns temporary security credentials that can be used to access AWS resources associated with the role.

Once the user has obtained temporary security credentials, they can use them to access AWS resources associated with the role until the credentials expire. The length of time that the credentials are valid can be set in the role's session duration policy. By default, this is set to one hour but can be increased up to 12 hours.

How is an IAM Policy different from an IAM Role?

An IAM policy and an IAM role are both used to control access to AWS resources. However, they serve different purposes.

An IAM policy is used to define permissions for a specific AWS resource or set of resources. It is attached to a user, group, or role to grant or deny access to those resources.

IAM policies are static and do not change based on the user, group, or role that is accessing the resources.

In contrast, an IAM role is a set of permissions that can be assumed by a user, group, or service.

It is a way to delegate access to AWS resources without the need to share long-term security credentials such as access keys.

When a user (or a service) assumes an IAM role, they inherit the permissions associated with the role. IAM roles are dynamic (opposed to policies) and can change based on the user, group, or service that is assuming the role.

IAM roles are useful for scenarios where you need to grant temporary access to a resource.

For example, you might have a script that needs to access an S3 bucket to upload a file. Instead of embedding AWS credentials in the script, you can create an IAM role that has permission to access the S3 bucket and then assume that role in the script.

Examples of IAM Policies

Here are some examples of simple IAM policies for common use cases:

Allow read-only access to an S3 bucket

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ]
        }
    ]
}

This policy allows a user to read objects from the example-bucket S3 bucket and list the contents of the bucket, but does not allow them to upload or modify objects.

Allow full access to an EC2 instance

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*"
        }
    ]
}

This policy allows a user to perform any action on any EC2 instance in the account.

Allow read-only access to an RDS instance

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBInstances",
                "rds:DescribeDBSnapshots",
                "rds:DownloadDBLogFilePortion"
            ],
            "Resource": [
                "arn:aws:rds:us-west-2:123456789012:db:mysql-db",
                "arn:aws:rds:us-west-2:123456789012:snapshot:mysql-db-snapshot"
            ]
        }
    ]
}

This policy allows a user to view information about the mysql-db RDS instance and download log files, but does not allow them to perform any modifications.

Allow read-only access to an SQS queue

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:GetQueueUrl",
                "sqs:ReceiveMessage"
            ],
            "Resource": "arn:aws:sqs:us-west-2:123456789012:example-queue"
        }
    ]
}

This policy allows a user to retrieve the URL of the example-queue SQS queue and receive messages from the queue, but does not allow them to send messages or modify the queue in any way.

Allow read-only access to a DynamoDB table

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DescribeTable",
                "dynamodb:GetItem",
                "dynamodb:Query",
                "dynamodb:Scan"
            ],
            "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/example-table"
        }
    ]
}

This policy allows a user to view the schema of the example-table DynamoDB table and read items from the table, but does not allow them to modify the table in any way.

Increase AWS Security Posture with IAM Roles and Policies

Using a combination of IAM roles and policies is an effective way to increase the security posture of an AWS account. Here are some best practices to follow:

Use Least Privilege

When creating IAM policies, it's important to use the principle of least privilege. This means granting users and roles only the permissions they need to perform their job functions and no more.

For example, if a user only needs read access to an S3 bucket, don't grant them write or delete access.

Rotate Credentials

AWS recommends regularly rotating access keys and secret access keys for IAM users and roles. This helps to reduce the risk of unauthorized access to your resources in the event that credentials are compromised.

Use IAM Roles Instead of Access Keys

IAM roles are a more secure way to grant temporary access to AWS resources than using access keys.

When a user assumes an IAM role, they get temporary security credentials that expire after a specified amount of time. This minimizes the risk of credentials being compromised and reduces the need to manage long-term access keys.

Use Managed Policies

AWS provides a number of managed policies that can be used to grant permissions to users and roles.

These policies are created and maintained by AWS and are designed to follow best practices for security and compliance.

By using managed policies, you can be sure that your users and roles have the appropriate permissions without having to create and maintain policies yourself.

Use Conditions in IAM Policies

IAM policies can include conditions that further restrict the permissions granted to users and roles.

For example, you can create a policy that only allows access to a resource during certain hours of the day or only from certain IP addresses.

Using conditions can help to further reduce the risk of unauthorized access to your resources.

Use Multi-Factor Authentication (MFA)

Enabling multi-factor authentication (MFA) for IAM roles is an effective way to increase the security of your AWS account.

MFA requires users to provide a second form of authentication, such as a hardware token or a mobile app, in addition to their password.

This makes it much more difficult for an attacker to gain unauthorized access to your resources even if they have obtained the user's password.

By following these best practices, you can significantly increase the security posture of your AWS account and better protect your resources from unauthorized access.

What have we seen

In this article, we explored the differences and similarities between IAM roles and policies in AWS.

IAM policies define permissions for AWS resources and are used to grant or deny access to specific resources in your AWS account.

IAM roles, on the other hand, are AWS identities with permission policies that determine what the identity can and cannot do in AWS. IAM roles are a way to delegate access to AWS resources without the need to create and manage long-term AWS credentials.

We also discussed the main elements of an IAM policy, including the version, statement, effect, action, resource, and principal. Additionally, we explained how to assume an IAM role in AWS using the AWS Security Token Service (STS) API.

To increase the security posture of an AWS account, we recommended using a combination of IAM roles and policies and following best practices such as using least privilege, rotating credentials, using managed policies, using conditions in IAM policies, and enabling multi-factor authentication (MFA) for IAM roles.

Overall, by understanding the differences between IAM roles and policies and following best practices, you will be better equipped to manage access and identity needs on the AWS platform.

I really hope that this little article has been of help for all of you, and as always, feel free to comment and reach us on our community slack.

Until next time, stay safe and see you in the next article, in which we’ll discuss about IAM Users and Groups! 😉

AWS IAM CLI: a cheatsheet

Alessandro Gaggia — Wed, 21 Jun 2023 14:32:49 +0000

AWS CLI stands for Amazon Web Services Command Line Interface.

It is an open-source tool, and knowing how to use it to interact with AWS Services is crucial, especially for Developers.

It allows to centralize control of all existing services from a single tool, and moreover, to make automated scripts.

AWS Identity & Access Management, IAM in short, provides fine-grained access control across AWS services.

This article will show how to use the AWS CLI to perform all the most common IAM operations.

Prerequisites and Tips

If you haven't installed the AWS CLI yet, start by looking at Installing the AWS CLI Guide from Amazon.
Download jq, a lightweight and flexible JSON processor for your terminal. Highly recommend for automated script with the AWS CLI. Look at the site for more information.
Get the AWS CLI version: $ aws --version.

Get the AWS CLI installation path: $ which aws.

Configure the AWS CLI for the first time: follow our previous article.
$ aws --cli-auto-prompt: enable Auto Completion mode for the CLI, giving you suggestions as you write down your commands. Just remember to exit this mode when you need to run scripts!

AWS CLI: Versions

Version 2.x — Used primarily for production environments.
Version 1.x — Now available only for backward compatibility.

AWS CLI: command anatomy

Users can create commands in single or multiple lines. The \ character splits a command into multiple lines for better readability.

In general, a command is structured in this way:

You have the CLI invocation, and then you apply a command to a specific service. You can also add many different optional parameters.

AWS IAM CLI: table of content

There are many different commands that you can exploit using the AWS CLI, but this article will focus only on those related to IAM and STS (AWS Security Token Service).

Because commands can have many optional parameters, we recommend opening this link in your browser for further reference information.

Below is a table of content you can use to navigate to a specific command.

Prerequisites and Tips
AWS CLI: Versions
AWS CLI: command anatomy
AWS IAM CLI: table of content
AWS IAM CLI: create user
AWS IAM CLI: list users
AWS IAM CLI: update user
AWS IAM CLI: delete user
AWS IAM CLI: create IAM policy
AWS IAM CLI: list IAM policies
AWS IAM CLI: update IAM policy
AWS IAM CLI: delete IAM policy
AWS IAM CLI: create IAM role
AWS IAM CLI: delete a Role
AWS IAM CLI: attach policy to a User
AWS IAM CLI: attach policy to an IAM role
AWS IAM CLI: list all policies attached to a user
AWS IAM CLI: list all policies attached to a role
AWS IAM CLI: jq snippets
Conclusions

AWS IAM CLI: create user

Create a new IAM user.

aws iam create-user --user-name AlessandroArticle

iam: Service
create-user: Command
--user-name: Name of the user

Output:



{
    "User": {
        "Path": "/",
        "UserName": "AlessandroArticle",
        "UserId": "<user_id>",
        "Arn": "arn:aws:iam::<account_number>:user/AlessandroArticle",
        "CreateDate": "<creation_date>"
    }
}

AWS IAM CLI: list users

Lists all users in the credentials’ set account.

aws iam list-users

iam: Service
list-users: Command

Output:



{
    "Users": [
        {
            "Path": "/",
                "UserName": "AlessandroArticle",
                "UserId": "<user_id>",
                "Arn": "arn:aws:iam::<account_number>:user/AlessandroArticle",
                "CreateDate": "<creation_date>"
        }
        ]
}

AWS IAM CLI: update user

Updates an IAM user. We can update the name of a user using the update-user command.

aws iam update-user --user-name AlessandroArticle --new-user-name AlessandroArticleNew

iam: Service
update-user: Command
—-user-name: The old name
—-new-user-name: The new name

AWS IAM CLI: delete user

Deletes the specified IAM user.

aws iam delete-user —user-name AlessandroArticle

iam: Service
update-user: Command
—-user-name: The name of the user to remove

Note: you must delete the items attached to the user before attempting to delete a user, otherwise the command will fail (as per AWS documentation):

Password ( DeleteLoginProfile )
Access keys ( DeleteAccessKey )
Signing certificate ( DeleteSigningCertificate )
SSH public key ( DeleteSSHPublicKey )
Git credentials ( DeleteServiceSpecificCredential )
Multi-factor authentication (MFA) device ( DeactivateMFADevice , DeleteVirtualMFADevice )
Inline policies ( DeleteUserPolicy )
Attached managed policies ( DetachUserPolicy )
Group memberships ( RemoveUserFromGroup )

Pro tips:

List userId and UserName



aws iam list-users | jq -r ‘.Users[ ]|.UserId+” “+.UserName’

Get single user



aws iam get-user --user-name (username)

Add user



aws iam create-user --user-name (username)

Delete user



aws iam delete-user --user-name (username)

List access keys for user



aws iam list-access-keys --user-name (username) | jq -r .AccessKeyMetadata[ ].AccessKeyId

Delete access key for user



aws iam delete-access-key --user-name (username) --access-key-id (accessKeyID)

Activate/deactivate access key for user



aws iam update-access-key --status Active --user-name (username) --access-key-id (access key)



aws iam update-access-key --status Inactive --user-name (username) --access-key-id (access key)

Generate new access key for user



aws iam create-access-key --user-name (username) | jq -r ‘.AccessKey | .AccessKeyId+” “+.SecretAccessKey’

AWS IAM CLI: create IAM policy

Creates a new IAM policy.

aws iam create-policy --policy-name example-policy --policy-document file://example-policy.json

iam: Service
create-policy: Command
--policy-name: Name of the IAM policy
--policy-document: Policy document in JSON format (useful because the policies are structured files)

An example policy document:



{
    "Version": "2012-10-17",
    "Statement": [
        {
              "Effect": "Allow",
              "Action": [
                "s3:GetBucketLocation",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads"
              ],
              "Resource": [
                "arn:aws:s3:::<my_bucket>"
              ]
            }
    ]
}

Output:



{
   "Policy": {
      "PolicyName":"example-policy",
      "PolicyId":"<policy_id>",
      "Arn":"arn:aws:iam::<account_number>:policy/example-policy",
      "Path":"/",
      "DefaultVersionId":"v1",
      "AttachmentCount":0,
      "PermissionsBoundaryUsageCount":0,
      "IsAttachable":true,
      "CreateDate":"<creation_date>",
      "UpdateDate":"<update_date>"
   }
}

AWS IAM CLI: list IAM policies

Lists IAM policies in the account.

aws iam list-policies --scopes All

iam: Service
list-policies: Command
--scopes: Policies scope. Possible values: All, AWS, Local. AWS is for managed policies, while Local for custom policies.

Output



{
    "Policies": [
        {
           "Policy": {
              "PolicyName":"example-policy",
              "PolicyId":"<policy_id>",
              "Arn":"arn:aws:iam::<account_number>:policy/example-policy",
              "Path":"/",
              "DefaultVersionId":"v1",
              "AttachmentCount":0,
              "PermissionsBoundaryUsageCount":0,
              "IsAttachable":true,
              "CreateDate":"<creation_date>",
              "UpdateDate":"<update_date>"
           }
        }
    ]
}

AWS IAM CLI: update IAM policy

Edit an IAM policy and set it as default.



aws iam create-policy-version \
 --policy-arn arn:aws:iam::123456789012:policy/my-policy \
 --policy-document file://NewPolicyVersion.json --set-as-default

iam: Service
create-policy-version: Command
--policy-arn: ARN of the policy
--policy-document: Updated policy file

AWS IAM CLI: delete IAM policy

Delete a policy given the ARN.

aws iam delete-policy --policy-arn arn**:**aws**:**iam**::**123456789012**:**policy/my-policy

iam: Service
delete-policy: Command
--policy-arn: ARN of the policy

AWS IAM CLI: create IAM role

Creates a new IAM role. The arguments for this command are:

aws iam create-role --role-name example-role --assume-role-policy-document file://assume-policy.json

iam: Service
create-role: Command
--role-name: Name of the IAM role
--assume-role-policy-document: Trust relationship policy document that grants an entity permission to assume the role

In this example, we will create an IAM role that grants AWS Glue permission to assume the role (as principal).



{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
        "Service": "glue.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
        }
    ]
}

Output:



{
    "Role": {
        "Path": "/",
        "RoleName": "example-role",
        "RoleId": "<role_id>",
        "Arn": "arn:aws:iam::<account_number>:role/example-role",
        "CreateDate": "<creation_date>",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Principal": {
                        "Service": "glue.amazonaws.com"
                    },
                    "Action": "sts:AssumeRole"
                }
            ]
        }
    }
}

AWS IAM CLI: delete a Role

Deletes an IAM Role.

aws iam delete-role --role-name Test-Role

iam: Service
delete-role: Command
--role-name: Name of the IAM Role to remove

AWS IAM CLI: attach policy to a User

To allow a User to do some actions, apply a policy to it.

aws iam attach-user-policy --user-name AlessandroArticle --policy-arn arn:aws:iam::<policy_id>:policy/my-policy

iam: Service
attach-user-policy: Command
--user-name: Name of the IAM user
--policy-arn: ARN of the IAM policy to attach

In this example, we will attach the IAM policy we created earlier to an example IAM.

AWS IAM CLI: attach policy to an IAM role

We can also attach a policy to a IAM role.

aws iam attach-role-policy --role-name example-role --policy-arn arn:aws:iam::<policy_id>:policy/my-policy

iam: Service
attach-role-policy: Command
--role-name: Name of the IAM role
--policy-arn: ARN of the IAM policy you want to attach

AWS IAM CLI: list all policies attached to a user

We can list all policies attached to an IAM User.

aws iam list-attached-user-policies --user-name AlessandroArticle

iam: Service
list-attached-user-policies: Command
--user-name: The User to whom the policies are attached to

Output



{
    "AttachedPolicies": [
        {
            "PolicyName": "my-policy",
            "PolicyArn": "arn:aws:iam::<account_number>:policy/learnaws-dynamo-policy"
        }
    ]
}

AWS IAM CLI: list all policies attached to a role

List all policies attached to an IAM Role.

aws iam list-attached-role-policies --role-name example-role

iam: Service
list-attached-role-policies: Command
--role-name: The Role to whom the policies are attached to

Output



{
    "AttachedPolicies": [
        {
            "PolicyName": "my-policy",
            "PolicyArn": "arn:aws:iam::<account_number>:policy/example-policy"
        }
    ]
}

Output:



{
    "UserId": "AROAJQ3ISEWFFR6GXAW:<user_name>",
    "Account": "637004329899",
    "Arn": "arn:aws:sts::637004329899:assumed-role/<role-name>/<user_name>"
}

AWS IAM CLI: jq snippets

Finally, thanks to the excellent tutorial from BlueMatador, here we present some fast snippets that integrate the *jq* tool to extrapolate useful info for different use-cases. Kudos to them 🙂.

List groups



aws iam list-groups | jq -r .Groups[ ].GroupName

Add/Delete groups



aws iam create-group --group-name (groupName)

List policies and ARNs



aws iam list-policies | jq -r ‘.Policies[ ]|.PolicyName+” “+.Arn’



aws iam list-policies --scope AWS | jq -r ‘.Policies[ ]|.PolicyName+” “+.Arn’



aws iam list-policies --scope Local | jq -r ‘.Policies[ ]|.PolicyName+” “+.Arn’

List user/group/roles for a policy



aws iam list-entities-for-policy --policy-arn arn:aws:iam:2308345:policy/example-ReadOnly

List policies for a group



aws iam list-attached-group-policies --group-name (groupname)

Add policy to a group



aws iam attach-group-policy --group-name (groupname) --policy-arn arn:aws:iam::aws:policy/exampleReadOnlyAccess

Add user to a group



aws iam add-user-to-group --group-name (groupname) --user-name (username)

Remove user from a group



aws iam remove-user-from-group --group-name (groupname) --user-name (username)

List users in a group



aws iam get-group --group-name (groupname)

List groups for a user



aws iam list-groups-for-user --user-name (username)

Attach/detach policy to a group



aws iam attach-group-policy --group-name (groupname) --policy-arn arn:aws:iam::aws:policy/DynamoDBFullAccess



aws iam detach-group-policy --group-name (groupname) --policy-arn arn:aws:iam::aws:policy/DynamoDBFullAccess

Conclusions

This article shows that AWS CLI is a powerful tool for automatic operations on AWS services.

In particular, we have used IAM and STS services to explore all the different commands that we can leverage for Access Management and Identity governance.

We have demonstrated that AWS CLI commands can be chained with other terminal tools to push even further your automation scripts.

Finally, we have seen how jq can be a perfect companion for the CLI to obtain properties out of JSON-formatted files or command results.

If this article interested you, next week we will continue with a new cheatsheet correlated to STS and how it is tied closely to our open-source tool Leapp. Don’t miss it out!

Thank you everyone, for coming this far. We hope that you enjoyed this little “cheatsheet”.

As always, if you have questions, clarifications, or just want to share your opinions, feel free to join our Top of the Ops community.

Until next time, stay safe 🙂!

What is a IAM Principal?

Alessandro Gaggia — Wed, 07 Jun 2023 13:06:45 +0000

Whenever you find yourself working with AWS access model, being a newbie or an experienced DevOps, there is a lot of terminology to digest and learn.

Users, Roles and Policies are terms that we learn pretty early in our career, however there is one concept that has a lot of meaning behind, and, in my opinion, deserve a little more explanation: IAM Principal!

IAM Principal: definition

Let’s start by giving a standard definition: a principal is a human user or workload that can make a request for an action or operation on an AWS resource.

Moreover a principal is anything, AWS related, that can send a request to AWS, via the Management Console, the AWS API, or the AWS CLI.

IAM Principal: actors

In AWS What or Who are the “actors” that can be referred as Principals?

Root User
IAM Users
IAM Roles/Temporary Security Tokens

The main differences among them are Who can impersonate them, and What credentials they are granted.

Users are impersonated by human users while Roles by services, or workloads in general.

Also, while the first are granted long-lived credentials, Roles use temporary credentials.

Root user

The Root user is the owner of the AWS main Account, and it should be protected by MFA and a strong password right after registering. We should avoid using Root user as a Principal, for security reasons, and instead use IAM Users and Roles.

He accesses AWS with email and password: that is why we must avoid using it for operation work!

IAM Users

An IAM user is a persistent entity that is given a set of credentials to manage services on AWS. The IAM User can be associated with both long or short-lived credentials (tough short-lived ones are much preferred).

An IAM User can be authorised to perform actions directly via an AWS Policy attached to it, or via a Group Policy.

An IAM User is created through:

AWS Management Console
CLI
SDKs

IAM Role

a IAM Role is a Principal associated directly to AWS Resources or assumed by a IAM User, the AWS CLI, or one of the AWS SDKs available. It has permissions granted via temporary credentials. It has one or more Policies attached to it.

Some use cases related to IAM Roles involve:

Amazon EC2 Roles: grant permissions to applications running on an Amazon EC2 instance.
Cross-Account Access: grant permissions to users from other AWS accounts, whether in control of those accounts or not.

Temporary Security Tokens:

Temporary Security Tokens are obtained from the AWS Security Token Service (STS).

They always have an expiration date and time, and have a lifespan between 15 minutes and up to 36 hours.

These tokens are usually obtained through a Federation Process, which involves granting permissions to users authenticated by a trusted external system.

Here is a summary from AWS showing some types of Roles/Temporary Security Tokens and from what they are obtained:

Principal	Type	Docs & Links
Federated User (Login via custom proxy architecture)	FederatedUser
Web Federated User (Login with Amazon, Amazon Cognito, Facebook, Google)	AssumedRole	https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc_user-id.html
SAML 2.0 Federated User	AssumedRole	https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html#CreatingSAML-userid
AWS SSO User	AssumedRole	https://dev.to/aws-heroes/adding-aws-sso-and-controlling-permissions-56ga

A special mention goes to AWS SSO Users that are configured via IAM Identity Center permission sets to access different accounts with different roles. When a user lands on an account a role is given transparently to access services and resources according to the policies set up by the administrator.

IAM Roles, AWS SSO, and Temporary Security Tokens are meant for advanced AWS IAM usage and have always a limited set duration of time.

Because these Principals are extremely important and versatile, I strongly advise reading more on the argument, starting from this article and also this one, concluding with this one from AWS Hero Matt Lewis.

IAM Principal: authentication, requests, and authorization

When working with Principals we must understand the two actions that must be taken to finally obtain a set of valid Credentials.

First Authentication of the subject against AWS or a valid Identity Provider, and then Authorization to be able to perform actions and access specific resources.

IAM Principal: Authentication

A Principal must always authenticate to send AWS requests.

Only Amazon S3, SQS, SNS, and AWS STS allow limited (and specific) requests from anonymous users, but they're the exception.

To log in as a Root User on the console, use your email and password.

As a Federated User, you can access AWS resources through IAM roles granted by your identity provider's authentication.

Enter your Access Key ID and Secret Access Key to authenticate as an IAM user.

To authenticate workloads, use temporary or long-term credentials (always preferring the first).

DevOps’ best practices recommend using MFA and temporary credentials to keep your account secure.

IAM Principal: Request

When a principal tries to do something with AWS using the AWS Management Console, an SDK, or the CLI, it sends a request to AWS with the following information:

Actions or operations: the actions to perform.
Resources: the AWS services or objects to manipulate.
Principal: and now we know what they can be 😀!
Environment data: various metadata, like IP address, User agent, etc.
Resource data: metadata depending on the specific AWS resource.

AWS puts all of these in a request context, which is used to evaluate and authorize the request.

IAM Principal: Authorization

After Authentication, you must also be authorized to complete your request.

During the authorization process, AWS uses the request context to check for policies that conform to the request.

It then parses the policies to determine whether to allow or deny the request.

Most policies are stored in AWS as JSON documents and specify the permissions for principal entities. There are several types of policies that can affect the outcome of the request.

If a single permissions policy includes a denied action, AWS denies the entire request and stops evaluating.

Because requests are denied by default, they can complete only if every part of the request is allowed by the permissions policies.

The general rules to understand how the authorization works are the following:

By default, all requests are denied.
An explicit allow (identity-based or resource-based) overrides the default deny.
Organizations SCPs, IAM permissions boundaries, or session policies overrides the allow. But if there are more than one of this policies, they all need to allow the request.
An explicit deny in any policy overrides any allows.

To learn more about how this process is evaluated, see Policy evaluation logic.

IAM Principal: Credentials

As we have seen there are two types of credentials granted to a Principal: long-lived and temporary short-lived.

Long-lived credentials last until an administrator explicitly removes them from a Principals and usually, are applied to Root Users and IAM Users/Groups.

Short-lived credentials are temporary, and have an explicit expiration date and time.

They are generated through AWS STS Service and are associated with IAM Roles, Assumed Roles, or even Federated Identities (AWS SSO, Web, SAML, OIDC, OAuth, Cognito, Azure AD, etc.)

IAM Principal: Best Practices

As short-lived credentials can also be applied to a Group or a User thanks to the Assume Role action, I strongly recommend adhering to DevOps best practices and always using short-lived credentials whenever possible.

It is preferable to use temporary credentials because they reduce the potential damage done by an attacker stealing them (they are limited in time).

It is also savvy to narrow down policies associated with users and roles to the bare minimum set of resources that you need for your work. Always take advantage of the Deny First rules!

With the Introduction of IAM Identity Center is always preferable for administrators to use it for creating new Users as they will also benefit from a landing panel to choose the account and role from.

Sum Up

In this short article, we learned about AWS IAM Principals, how they are categorized, and what they stand for.

We have learned that IAM Principals have to deal with both an Authentication and an Authorization process to be able to operate successfully on AWS.

We have seen what a request, made to AWS by a Principal, contains.

We have seen what a Root account and an IAM User are, how they differ from IAM Roles, and moreover from Temporary Security Tokens.

We have analysed the differences between Long and Short lived Credentials, and why the latter are preferable and more secure.

We have proposed some basic best practices to follow to better use your AWS Principals.

So, thank you all for reaching the end of the article!

As always, if you have suggestions or questions, feel free to come and have a chat with us on our slack community.

Until next time, see ya and stay safe! 🙂

How to fix response did not contain a valid saml assertion

Alessandro Gaggia — Fri, 21 Apr 2023 12:31:18 +0000

If you read this article, you are managing user identities outside of AWS and using Identity Provider (IdP) Federation to give these external identities permission to use AWS resources in your account.

In this authentication process, one of the most common errors you may need to confront is "response did not contain a valid saml assertion," and in this article, I want to share with you some troubleshooting advice to solve it.

Investigating a No valid assertion found in SAML response

Checking the attribute name and attribute value on your IdP

If you are on AWS (but in general), invalid SAML assertion mainly occurs when the SAML response from the IdP does not include an attribute with the Name set to https://aws.amazon.com/SAML/Attributes/Role . The attribute must also contain one or more AttributeValue elements, each with these two strings, separated by a comma:

The ARN of a role that the user can be mapped to
The ARN of the SAML provider

E.g.:

<Attribute Name="<https://aws.amazon.com/SAML/Attributes/Role>">

<AttributeValue>arn:aws:iam::account-number:role/role-name1,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>

</Attribute>

Here is also an example of a resolution for Okta.

Time Synchronisation issues between IdP and Service Provider

https://docs.pulsesecure.net/WebHelp/Content/PCS/PCS_AdminGuide_8.2/Investigating a No valid assertion.htm

If the SAML IdP and SAML service provider (AWS, for example) clocks are not synchronized, the assertion can be determined invalid, and authentication fails.

A possible solution is to verify that your IdP and Service provider can share the same NTP server or prove that your server's clock is up-to-date.

Metadata.xml mismatch

Data refreshes, and upgrades can cause the certificates to be no longer trusted by one side of the Federation process or the other. Try to check and update the metadata.xml on both ends so the certificates will match again.

SAML message not properly formatted, with missing or invalid elements

https://stackoverflow.com/questions/64158310/aws-sso-your-request-included-an-invalid-saml-response

Sometimes the error occurs not only with the User attribute but in general if the message needs to include all the required information in the required format. For example:

The message was signed, but the signature could not be verified.
Assertion contains an unacceptable Audience Restriction.
The assertion is no longer valid, or the message is expired, see Time Synchronisation issues between IdP and Service Provider.
SAML response contained an error indicating that the Cloud Provider received a SAML message from an IdP with an error status code.

Remember that SAML is schema-compliant, so you must adhere to its standard when creating its XML request. Make sure to refer to this document to see all the standard tags.

Some more examples of possible typos can be:

Not including encoding at the beginning of the XML:

<?xml version="1.0" encoding="UTF-8"?>

Typo in the Recipient of the SubjectConfirmationData : set it to "https://signin.aws.amazon.com/saml."
Not including an AuthnStatement.

How to view a SAML response for troubleshooting

https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml.html

This article has several ideas to help you narrow down the exact cause of the issue. Still, I'd also like to give you some basic tips on debugging the SAML assertion you receive to find details that can point you to the root cause of your problem.

Google Chrome and Firefox

Press F12 to start the Developer Tools console.
Select the Network tab, and then select Preserve log (Persist Log in Firefox)
Look for a SAML Post, then view the Payload tab at the top. Look for the SAMLResponse element that contains the Base64-encoded response.
Copy it.

💡 Security Note: as SAML assertions contain sensitive information, I discourage you from using online base64 decoders and using one of these simple scripts to do it from your local terminal.

Windows systems (PowerShell):

PS C:\\>[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("base64encodedtext"))

MacOS and Linux systems:

$echo "base64encodedtext" | base64 --decode

Also, if the attributes from your Identity Provider are not encrypted, the Firefox browser SAML tracer Add-on or Chrome SAML Message Decoder can view these attributes.****

Tutorials

To help you further, here are two articles from our blog where we share some hints to configure SAML with GSuite (note that concepts and properties are similar to other IdPs).

Conclusions

In this article, we have seen how to troubleshoot a very pesky error of the SAML Federation: "Response did not contain a valid SAML assertion."

We have shown that it can occur when:

Role attributes are not set correctly in the SAML request - IdP side.
There is a time desynchronization between the IdP and the Service Provider.
There is a Metadata.xml mismatch between the actors, so the certificate doesn't match.
There are typos or an invalid SAML structure in your request.

In general, I always return to this link when I need to troubleshoot a SAML response, as the problem may lie on a different configuration depending on the IdP you're using.

This little article has been of help to all of you, and till next time, Happy SAML assertions, and see you in the next article! 😉

How to quickly automate AWS Federated Session generation with Leapp CLI

Alessandro Gaggia — Thu, 21 Jul 2022 13:38:43 +0000

Introduction

Ever wanted to create and use your personal AWS Federation with Google as an IdP in a programmatic way?

This short article will surely come to the rescue, introducing some of the features of Leapp CLI.

Let’s start!

Prerequisites

AWS Account access with adeguate IAM privileges
Google Suite access with Admin privileges

Before creating a Federated session using Leapp CLI, we must set up our Google IdP in AWS.

We can refer to our guide as a guideline, but for this article, let’s review some important key values here.

The AWS IAM Federation gives the ability to assume a role with permissions to do actions on AWS resources to an external user. This operation can generate temporary credentials for both programmatic access (CLI or SDKs) and for console access.

We will focus on programmatic access.

Trust between Google and AWS depends on 2 metadata files, one from AWS that must be passed to Google and one from Google that also contains keys that AWS can use to validate authentication responses (assertions) from your organization.

Another useful guide to set up things on your side is this one from AWS, which shows how the Federation mechanism works, and this one from ***Krishna Modi,* which clearly shows the setup on Google’s side.

Federated access via Leapp CLI

You can download Leapp CLI by following the instructions in our official documentation.

💡 Note that you also need the Leapp Desktop App in order to use the CLI

After that, we can create a script that allows creating a new Federated Session:

#!/bin/bash
# Make a new Federated Session

# Get Parameters
while getopts ":s:r:a:u:n:" flag;
do
    case "${flag}" in
        s) name=${OPTARG};;
        r) awsregion=${OPTARG};;
        a) idparn=${OPTARG};;
        u) idpurl=${OPTARG};;
        n) rolearn=${OPTARG};;
    esac
done

echo $name
echo $awsregion
echo $idparn
echo $idpurl
echo $rolearn

# Find Default Profile ID
profile=$(leapp profile list -x --filter "Profile Name"=default | grep default | cut -d " " -f2)
echo $profile

# Create Session
leapp session add --providerType aws --sessionType awsIamRoleFederated --sessionName $name --region $awsregion --idpArn $idparn --idpUrl $idpurl --profileId $profile --roleArn $rolearn

You can remove the echo command, which is there to show you that all the arguments are passed correctly.

You can invoke the command like this:

./testScript.sh -s MYTEST -r eu-west-1 -a FAKEARN -u https://fakeurl.com -n FAKEROLEARN

💡 Note: remember that all arguments are mandatory. You can also modify the script to give the session a different profile; here, we use the default one.

This is the output, taken directly from my console and my Leapp Desktop App, to show synchronization is working correctly.

Bonus: create a chained session from the Federated one

Usually, Federation is used to Access a Landing Zone, but most of the time, you want to access another account (i.e. one of your clients to work on a project).

Here I’ll show how to create a chained session from a federated one:

#!/bin/bash
# Make a chained from a Federated session

# Get Parameters
while getopts ":s:r:n:p:" flag;
do
    case "${flag}" in
        s) name=${OPTARG};;
        r) awsregion=${OPTARG};;
        n) rolearn=${OPTARG};;
        p) parentname=${OPTARG};;
    esac
done

echo $name
echo $awsregion
echo $rolearn
echo $parentname

# Find Parent Session ID
parentid=$(leapp session list -x --filter "Session Name"="$parentname" | grep $parentname | cut -d " " -f2)
echo $parentid

# Find Default Profile ID
profile=$(leapp profile list -x --filter "Profile Name"=default | grep default | cut -d " " -f2)
echo $profile

# Create Session
leapp session add --providerType aws --sessionType awsIamRoleChained --sessionName $name --region $awsregion --profileId $profile --roleArn $rolearn --parentSessionId $parentid

And this is the result:

As you can see, the properties are correctly imported from the CLI:

Conclusion

In this small tutorial I’ve shown how it is possible to create a Federated Session directly from your terminal using Leapp CLI!

Also, we have seen that scripts leveraging the Leapp CLI can be combined together to achieve even more interesting results (i.e. creating a Chained Session from a Federated one).

This is just the first of a series of small tutorials we, as the Noovolari team, will propose to you all to show how you can automate some of your credential processes using Leapp CLI.

As always, if you have suggestions or questions, feel free to come and have a chat with us on our community slack.

Until next time, see ya and stay safe! 🙂

Stop putting AWS credentials in the credentials file

Alessandro Gaggia — Fri, 27 May 2022 08:37:07 +0000

From Ben Kehoe thread to an OSS tool for the on-demand credentials generation

To me, Everything started with this Twitter thread and from that article, by Ben Kehoe:

When dealing with CLI or SDKs, we are already used to putting IAM credentials in the .aws/credentials file.

However, as correctly stated cluttering the credentials file with many credentials is not the right move to make.

This article aims to overview what IAM Principals are and the better ways to manage your programmatic access to AWS.

Moreover, we'll focus on the Credential Process. We'll see that we can polish our local usage of AWS Principals with it.

Let's dig into this journey through AWS authorization systems.

Let's start with some basics: IAM Principals!

Stating the official documentation: "A principal is a person or application that can request an action or operation on an AWS account or resource."

IAM Principals can either be the User Root Account or an IAM entity (User or Role).

Because Root Account, following best practices, should not be used for programmatic access, and IAM Users are not a dynamic way to manage AWS identities, the provider is pushing users to use IAM Roles.

AWS Roles can be used to grant permissions to external Identity providers (Okta, OneLogin, AzureAd, and more..) to assign them to SSO Identities.

By using AWS Roles, an entity can also obtain permission in another existing AWS account via the assumeRole technique.

You obtained your Principal. Now what? Gain access to other Accounts!

One of the best things about IAM Roles is that they can be "assumed" by letting other entities (Users, Services, Applications) act on behalf of that role.

Here is a comprehensive article that explains how you can gain access to other AWS accounts!

AWS SSO: it's an authentication process, not a Principal!

Ok, we have seen how to use Principals in the most common scenarios.

We also know that it is common for companies to divide their tenants or simply their workloads into different accounts to maintain isolation and simplify governance and management.

In a modern AWS environment, AWS advice is to use AWS Organizations.

Courtesy of Amazon Web Services

AWS Organizations allows for AWS Single Sign-On, which is the ability to authenticate a valid external Identity, into the AWS ecosystem, through a Federation Process.

One important thing to understand clearly is that AWS SSO is not a Principal! AWS SSO allows for authentication inside AWS by external meanings, but it does not handle authorization against AWS services.

AWS associates one or more IAM Roles to an authenticated user via AWS SSO to manage authorization.

Signing API requests to AWS

You can put AWS credentials inside credentials or config files. But do you know how AWS effectively authorizes requesters made with those credentials? With a process called Signature V4.

Access key id, secret access key, and session token are used to sign the HTTP requests you make to AWS services, verifying the principal accessing the service.

They never get included in the request. Instead, you use it to create a cryptographic signature for the request.

While SigV4 is embedded in all the AWS SDKs, it is not exposed to being used independently (e.g., API Gateway requires SigV4 signatures on requests that can't be made through the SDK).

AWS Credentials file and temporary credentials

A credentials file is a plain text file, located typically in the ~/.aws/ folder. They can be long-lived (AWS IAM User) or short-lived (AWS IAM Role).

The credentials format is the following:

[default]
aws_access_key_id = <YOUR_ACCESS_KEY_ID>
aws_secret_access_key =<YOUR_SECRET_ACCESS_KEY>
aws_session_token=<AWS_SESSION_TOKEN> #short-lived only

They are used directly (with a specific profile or with a default one) by AWS CLI and SDKs.

They are directly associated with an IAM Principal.

What are the caveats of such an approach? Let's describe some:

AWS SSO

It can be a pain to manage as we now know that AWS SSO is not a principal, so it cannot be used directly and needs a way to obtain its role to generate temporary credentials.

While this is not a problem per se, AWS CLI currently does not give an easy way to view which role is associated with a specific SSO user, and SDKs require custom code to obtain usable credentials.

So, in general, AWS SSO still needs much manual intervention to be used effectively for programmatic access.

Short-lived credentials used in the credentials file can't be auto-rotated by AWS

Being set either manually or via third-party tools, temporary credentials inside the credentials file can't be rotated automatically. Ben Kehoe stated in his article that good practice should require the opposite.

There are some particular scenarios in which this can cause serious difficulties:

Long-running processes: if you start a long-running third-party process, temporary credentials will expire along the way, generating exceptions in the task. It is a credential manager's responsibility to take care of the expiration.
Third-party tools for automatic rotation: it is challenging to handle rotation without disrupting external processes.

General cluttering of credential files

As correctly stated by Ben in his article, the credentials file usually becomes a list of long and short-lived credentials and different profiles.

This list is not secure and challenging to manage.

Is there a better way to manage all AWS access to services and accounts? Yes, it's called Credential Process

The credential process handles AWS credentials to allow a third-party tool to generate credentials when requested by AWS CLI, APIs, or SDKs.

By putting a named profile configuration set in the config file located in ~/.aws/config formatted like below:

[profile PROFILE_NAME]
credential_process=PROCESS_GENERATING_CREDENTIAL_PATH_SCRIPT
region=REGION

The credential_process variable tells AWS how to request valid temporary credentials when needed.

The credential process requires the external tool to return valid credentials in the format:

{
    "Version": 1,
    "AccessKeyId": "an AWS access key",
    "SecretAccessKey": "your AWS secret access key",
    "SessionToken": "the AWS session token for temporary credentials",
    "Expiration": "ISO8601 timestamp when the credentials expire"
}

Setting the expiration time variable allows AWS to know precisely when requesting the credentials again without disrupting the external process requiring AWS.

Why is it better to use the credential process than the credentials file? Credentials auto-rotation!

One of the major drawbacks of using temporary credentials in the credentials file is that there is no simple and intelligent way to refresh expired credentials, not without compromising a long-running process or essential operations.

There is another significant benefit: no credentials are written on your machine, in files, or environment variables.

Even if the credential process is the way to go, there are still some important factors to consider:

Credential Process credentials generator: this implies that the tool you're using can handle diverse IAM Principals.
Caching credentials: because credentials generation is demanded by an external tool, caching credentials efficiently is also requested.
Cluttering: avoid a long list of config rules.

Here is where the OSS project Leapp can be your handiwork. Leapp can manage all major IAM Principals and AWS SSO, converting all of them into viable temporary credentials.

Leapp is a valid credential process for AWS:

[profile PROFILE_NAME]
credential_process=leapp session generate SESSION_ID
region=REGION

In combination with the Desktop App, the config file itself can be managed by the App:

Conclusions

In this article, we have come down a long journey through all the aspects of IAM Principals and how they are used to gain programmatic access to the plethora of services that AWS offers.

We have seen how AWS SSO works with AWS Organizations and why it must not be mistaken for a Principal. But we have also seen all the advantages of AWS Organizations over regular cross-account access.

Signature V4 was also explained, giving hints on how AWS authorizes requests coming from CLI and SDKs.

We have understood the differences between credentials file and credentials process and why the latter is nowadays a much-preferred solution for long-running processes and strict security compliances.

Finally, we have discussed Leapp, our open-source tool, showing how it can help deal with the credentials process.

Have questions? Want to propose a solution? Need to request something particular? Drop a line on my Twitter or come and join us in our slack community and share your thoughts.

So that's all folks, till the next article, goodbye and stay safe 😷.

*This article was written in pair with my co-worker @alessandro Gaggia (@balubor)

Shortcut for AWS CDK credentials: insanely simple setup for SSO, SAML, and named profiles

Alessandro Gaggia — Thu, 12 May 2022 09:34:45 +0000

Introduction

We all love CDK! Don’t we all? Since its introduction, we’ve finally got a Typescript tool to write IaC on AWS precisely and structured for serverless applications.

But there is a crucial point that is not as agile as it could be: local credentials management.

There is no simple way to re-use the same template in different environments without writing complex scripts and extensively using environment variables.

Another point is that you are usually bound to long-term credentials most of the time, and that is a possible security threat.

Lastly, according to the documentation, CDK partially supports Single Sign-on credentials. See this issue.

Not only for SSO but currently, there are still some open issues that can potentially be addressed using Leapp.

For example, this issue requests MFA caching. Currently, CDK prompts the user for MFA code every time a request is issued. Leapp can avoid this as it correctly caches credentials until the session token is expired.

Furthermore, inconsistency issues like this one are easily avoided as Leapp manages the credentials file for you.

But fear not! This article will show you how you can improve your CDK templates by making wise use of our open-source tool.

You’ll see that it is possible to automate credentials generation outside the template – keeping it drier and more straightforward – use SSO and having more than one credential set active simultaneously. This reduces the possibility to deploy to the wrong environment to zero by using named profiles.

We have prepared a simple test case that you can follow along to understand what are the possibilities and what you can do in your own project. Let’s begin!

It all starts with a simple example

To better understand what advantages our tool can give to a developer, we want to show you snippets of CDK code and terminal commands without and with Leapp.

Our example consists of a CDK template to deploy the same S3 bucket in two different accounts. Even if very trivial, its purpose is to demonstrate how you can simplify your code by introducing Leapp into your developer routine.

Bootstrap

When using CDK you first have to bootstrap the AWS environments that you want to deploy your infrastructure in, if you haven’t already. Without Leapp, you would normally use this cdk bootstrap command, as suggested by official AWS documentation:

cdk bootstrap aws://ACCOUNT-NUMBER-1/REGION-1 aws://ACCOUNT-NUMBER-2/REGION-2

In this example, we bootstrapped both the accounts you’ll need in a single command. The workload is error-prone, not safe, and can become very difficult to manage if you need to bootstrap lots of them.

With Leapp, you need one or more sessions already set up (don’t know how to? Check it here!). Go to the desktop app, select your session and double click it.

You can also change the region and named profile for that session. Left-click on it and select Change → Region/Named Profile

Now you can type cdk bootstrap and CDK will automatically bootstrap the session with the default named profile in the region that you selected. When bootstrapping multiple accounts, or if you’re not using the default named profile, add the flag cdk bootstrap --profile NAMED_PROFILE

If you don’t want to leave your terminal, you can use the newly released Leapp CLI!

Use the command leapp session start to select which session to start, change its region and named profile if you need to with leapp session change-region and leapp session change-profile and then you’re set!

Synth and Deploy

First thing first! For our example to deploy properly, when you instantiate your CDK stack, make sure to set env in your props to the following value:

{ 
    account: ***process.***env.CDK_DEFAULT_ACCOUNT, 
    region: ***process***.env.CDK_DEFAULT_REGION
}

In a default CDK project created using cdk init, you can find this file inside the bin folder, and it’s also referenced in the cdk.json file.

Once everything’s ready and the accounts are properly bootstrapped, start your sessions in Leapp as you did for the bootstrap step. Remember to change region and named profile accordingly. If you want to reduce the possibility of error to the minimum, you can programmatically do that in a script using custom flags. Check the Bonus section!

cdk deploy will deploy in the default named profile session you set in Leapp.

cdk deploy --profile NAMED_PROFILE will deploy in a different named profile instead.

Use Single Sign-on with CDK

As we said before, CDK only partially supports credentials generated by AWS Single Sign-on, BUT with Leapp it is possible to overcome this limitation. And without changing anything in your scripts too!

You have to create an *integration *****in Leapp, like you would for an AWS session. See the video below:

By doing so, you’ll recover all your Organization accounts and roles; now you just have to start one of your SSO sessions and Leapp will create short-lived credentials completely compatible with CDK!

Boom! Now you’re using SSO with CDK without hassle!

Credential Process

All the examples shown until now are based on short-lived credentials, which is awesome, but even if temporary, you are still leaving an open door to potential attackers: credentials in AWS files are still in plain text and therefore exploitable.

To overcome this issue AWS also gives the ability to generate credentials on the fly, right before issuing an SDK or CLI command. This feature is called credential process!

[profile default]
credential_process = leapp session generate SESSIONID

Leapp overwrites the AWS config file command by adding the correct session ID for you and using its CLI to generate credentials in place of AWS.

By doing this, every time CDK needs to access one or more SDK commands, Leapp will automatically issue valid credentials, without writing anything in your files!

And of course, it works with named profiles too!

Bonus: How to use Leapp CLI to automate CDK deploy

Leapp comes with a CLI, which allows to automate all the actions you can do with the Desktop App via flags.

In this simple snippet we want to show you how to create a named profile, associate it with a new AWS IAM User session, start that session and deploy your infrastructure, by setting a profile name beforehand.

PROFILE_NAME=my-profile-name
&& leapp profile create --profileName $PROFILE_NAME 
&& PROFILE_ID=$(leapp profile list -x | grep $PROFILE_NAME | awk '{print $1}') 
&& leapp session add 
    --providerType aws 
    --sessionType awsIamUser 
    --profileId $PROFILE_ID 
    --sessionName MY-SESSION-NAME 
    --region eu-west-1 
    --accessKey ACCESSKEY 
    --secretKey SECRETKEY 
&& SESSION_ID=$(leapp session list -x | grep 'MY-SESSION-NAME' | awk '{print $1}') 
&& leapp session start --sessionId $SESSION_ID 
&& cdk deploy --profile $PROFILE_NAME

To conclude

In this article, we’ve seen how you can improve the security of your CDK templates by leveraging Leapp as your credential management system.

By using Leapp, you don’t need to write any long or short-lived credential neither in your credential (or config) file nor environment variables. And by using the credential process feature you don’t need credentials at all!

We have shown how CDK supports named profiles which is a feature also managed by Leapp, so you can keep all your credentials active simultaneously, reducing the context switch between your IDE and Leapp.

We have showcased some scripts that let you integrate your CDK work routine with Leapp CLI to simplify your daily operations even further.

Thanks to Leapp generating temporary credentials from AWS SSO sessions, we have seen that you are also indirectly enabling Single Sign-on.

We hope that these slight improvements will make your day-by-day work easier. So, what are you planning to do with CDK? Do you have any suggestions on how we can improve Leapp? Come say “hi” in our community!

Until next time, goodbye and stay safe 😷

Noovolari team.

10 best practices to secure your AWS environment

Alessandro Gaggia — Thu, 10 Mar 2022 14:29:41 +0000

You registered to AWS. You are eager to start using it.

You want to solve the problem that drove you to Amazon Web Services in the first place.

However, when starting to use a Cloud Environment for work, security must be addressed first.

You need to secure your AWS resources, especially your accounts, from possible attacks. In this article, I want to describe 10 best practices to follow to help you put your mind at peace when working with AWS.

Let’s start!

Create Strong, Secure Password

Always use randomly-generated solid passwords with at least 24-30 characters, symbols, uppercase letters, and numbers.

Because these passwords are complex, always use a secure vault to store and retrieve them easily. Something like LastPass or BitWarden can help! Give it a try.

Multi-Factor Authentication Everywhere

AWS allows for Multi-Factor Authentication for the root account (indispensable) and other accounts. Try to consistently enforce MFA whenever possible if you don’t want your account hacked, or else...

To enable MFA for the root account, follow this guide. To enforce MFA for IAM users, follow this guide instead.

If you are a developer and need to access programmatically, you can use Leapp to access with MFA.

Remember also that:

You can add more than one device (or virtual device) per account or user.
You can replace or “rotate” a device.

Remove credentials from your root account

Your root account must be used only once to register to AWS and must NOT be used for anything else, as it can access everything in your environment. One of the first step*s is removing programmatic access from it*.

Create an IAM user and grant that user only the permissions needed for the APIs you plan to call.

Follow this guide to understand how to do it.

Enable CloudTrail logging, store trails into separated account

Log everything that happens in your AWS environment for security breach detection and investigation with CloudTrail.

The following best practices are general guidelines: you can tweak them as you see fit!

Apply trails to all AWS Regions: ensure that all events that occur in your AWS account are logged.
Enable CloudTrail log file integrity: lets you know if a log file has been deleted or changed.
Always store the logs in a separate account: enforce strict security controls, access, and segregation of duties.
Use AWS KMS managed keys instead of standard S3-SSE: to provide a directly manageable security layer.

Get started with this guide.

Operate with IAM users, groups, and roles

Don’t use the root user for your everyday routine.

Instead, citing AWS: adhere to the best practice of using the root user only to create your first IAM user.

Then you can safely store away access and secret credentials. You’ll generally not be needing them unless there are a few specific tasks.

IAM users represent an IAM identity capable of doing operations on AWS resources. User Groups are collections of IAM users seen as a unit. Finally, a role is attached directly to a resource and allows it to perform operations on other resources.

By exploiting these instruments, you can isolate and manage who or what is doing something in your environment in a more structured way.

Apply the Least Privilege Principle on IAM policies

Avoid policies with Administrator access for everything!

Start with a Deny All permission and slowly add permissions for specific services you need for the task: this way, you’ll adhere to the Least Privilege principle.

This is a small list of tricks that you can use to define the perfect policy for your service!

Also, there is an open-source tool you can use to define your policy.

Use AWS Organizations to set up your project accounts

AWS Organizations is an account management service that enables the central management of multiple accounts. You can define your organizational structure to better sort and scope account usage with Organizational Units.

Also, AWS Organizations include consolidated billing to see the overall breakdown of expenses. This helps you find anomalies quicker.

If you have AWS Single Sign-On enabled in your Organization, you can access programmatically to your eligible roles through Leapp.

AWS Organization uses Service Control Policies for security purposes, which act on top of IAM Policies across all accounts, limiting their maximum available permissions. Applied to Organizational Units help define permission boundaries in different company areas.

Follow this guide to help you correctly set up your landing zone and your project’s accounts.

Enable AWS Config rules and Billing Alarms

AWS has instruments to verify tampering or unwanted use of AWS Resources.

AWS Config provides a detailed view of AWS resources’ configurations in your account. This includes how they are related to each other and how they were configured in the past. AWS Config allows us to understand how they have changed over time.

Setting up AWS Config is an excellent way for proactive and detective actions. Use this guide to configure it and remember to enable AWS Config in all accounts and Regions.

This is an industry best practice recommended by the Center for Internet Security.

Billing alarms and Billing thresholds are another great way to be notified if something is not right in your account. Configure them like this guide, remembering to apply clean and meaningful TAGs to all resources.

Apply security at all layers

When building a project with AWS, always strive to secure all layers of your application and your environment:

Apply HTTPS as protocol; you can do it with services like API Gateway, CloudFront, LoadBalancers, even with plain EC2 instances; also remember mutual TLS authentication if you are developing a B2B application.
Apply security groups to your resources to manage carefully what CIDR, specific IP addresses, and Ports can communicate in and out of your environment.
Try to apply a good network design, isolating all the resources that don’t need direct Internet access in private VPCs, thus reducing ingress to selected Gateways that are easy to monitor.
Always apply encryption in transit and at rest whenever possible. Remember that AWS offers direct encryption in S3, KMS for key management, and the ability to encrypt EBS volumes directly.

Use temporary generated credentials

Credentials and .aws folder are possible vectors of malicious attacks.

To secure all your credentials and remove the hassle of creating temporary credentials via IAM Simple Token Service, I would suggest the open-source project Leapp.

Some of its features at a glance:

Cloud credentials generation in 1 click
Data stored locally encrypted in the OS System Vault
Multiple Cloud-Access supported strategies
Automatic short-lived credentials rotation
Automated provisioning of Sessions from AWS Single Sign-on
A friendly and slick user interface 🙂

Conclusions

With all these tips and tricks, I hope to have shown you how you can enhance the security posture of your AWS Cloud Environment.

Until next time, stay safe, and thanks for reading.

Noovolari team.

Until next time, see you all 🙂.

AWS SDK: "Unable to locate credentials", a cheat sheet for solving the issue

Alessandro Gaggia — Thu, 21 Oct 2021 14:09:14 +0000

How often do you find yourself working with your carefully prepared code, with AWS SDK in place for calling all of your services, and...nothing, it seems that your credentials are missing, even if you have configured them correctly?

If you've incurred this problem at least once, you're in the right place! We'll see together how to mangle with typical use cases, with an eye on security concerns.

The Credentials provider chain

First things first! To understand why you'll receive these errors, you must know how AWS searches for valid credentials.

That is the credentials provider chain! Some locations in your computer can hold credentials, as stated by AWS.

When you initialize from the SDK a new service client without supplying credentials directly (supply credentials directly in code is a bad practice, by the way), the SDK attempts to find AWS credentials by searching them in this order:

Environment variables: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.
Web Identity Token credentials: from the environment or container.
The default credential profiles file: ~/.aws/credentials, which is the most common location, or the config file: ~/.aws/config, generated with the CLI command aws configure.
Amazon ECS container credentials: from the Amazon ECS if the environment variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is set.
Instance profile credentials: used on EC2 instances and delivered through the Amazon EC2 metadata service.

If credentials are not set at least in one of the places or overlapping in a way that is not intended, then an error is likely to occur. Let's begin with some well-known use cases.

Unable to locate credentials: install the AWS CLI and run an aws configure!

It is always better to install AWS CLI, even if you don't plan to use it; you'll see that there are plenty of advantages to installing it. For example, once installed, it is possible to run aws configure, which will set all the required files for you to start using environment credentials and stop using hardcoded ones.

Let's see how it can be compiled:

Missing credentials in config: when code order matters!

Let's take for example the Javascript SDK, but the same case applies to all AWS SDK: if you have changed your credentials after some operations your Javascript client will not read the updated credentials unless you call an explicit config update, just like this:

AWS.config.loadFromPath('./AwsConfig.json');
// OR for example in case of temporary new credentials
AWS.config.update({
      sessionToken: sessionToken.aws_session_token,
      accessKeyId: sessionToken.aws_access_key_id,
      secretAccessKey: sessionToken.aws_secret_access_key,
});
// THEN for example
var s3 = new AWS.S3();

So it's important to call an explicit update of the AWS library before instantiating a client.

Temporary credentials generated programmatically, out of synch!

It's rare, but it may happen: sometimes, depending on the SDK version, especially for Javascript, for some services, the credentials are not working as expected and may seem out of synch with the AWS service.

In this case, there could be two potential fixes:

try to update the library. It is not so uncommon to see the error disappearing after an SDK update;
Your clock could be out of sync. Check if, for some reason, it is not showing the right time.

Check environment variables when running terminal commands from code

Sometimes using libraries or tools for launching terminal commands and scripts can be a huge help. Let's consider Node's require('child_process').exec, a very interesting method for spawning child processes.

Still, when used in a sandboxed application (i.e., Electron ones), it runs without your user's environment variables, thus making your credentials useless unless you set them explicitly in the environment option like this:

const env = {
  AWS_ACCESS_KEY_ID: aws_access_key_id,
  AWS_SECRET_ACCESS_KEY: aws_secret_access_key,
  AWS_SESSION_TOKEN : aws_session_token
};
exec(<command>, { env: env });

Even if this is a Node/Typescript example, the same principle still applies for Python, Rust, Go, and so on. Check if the command is issued with the proper environment set, it will save you a lot of time and trouble!

Privileged access comes with a price: watch out for sudo!

This particular error is nasty as you typically have your proper credentials in place.

That is, you run either a CLI command or invoke a terminal command (or script) from code, and credentials are missing!

This happens because sudo changes your $HOME directory from ~/USER to /root, removing most bash variables like AWS_CONFIG_FILE from the environment. Make sure you do everything with AWS as root or as your user, don't mix.

Sidenotes

If you have the CLI installed: try running aws configure list to see what credentials are set
If you are uncertain about a particular credentials error, run the command you want by CLI using the --debug option.

Conclusions

Managing all credentials by hand and constantly keeping an eye on what is active and what is not can be very troublesome.

What about security?

It is highly inconvenient to use long-lived credentials (i.e., IAM user) in both the environment variables and the credentials file, let alone forget to remove them once they are unnecessary.

Leaving credentials exposed like this allows for potential attacks on your AWS account or that of your client. You want to increase security is to use short-lived credentials whenever is possible to limit an attacker's blast radius (they can be used for an hour at maximum).

Noovolari / leapp

Leapp is the DevTool to access your cloud

Leapp

Website | Roadmap | Blog | TOPS community | Documentation | Troubleshooting

⚡ Lightning Fast, Safe, Desktop App for Cloud credentials managing and generation

Leapp is a Cross-Platform Cloud access App, built on top of Electron.

The App is designed to manage and secure Cloud Access in multi-account environments, and it is available for MacOS, Windows, and Linux.

For more information about features go to our documentation.

✨ Features

Cloud credentials generation in 1 click
Data stored locally encrypted in the OS System Vault
Multiple Cloud-Access supported strategies
Automatic short-lived credentials rotation
Automatic provisioning of Sessions from AWS Single Sign-on
Open multiple AWS console from different AWS accounts in Firefox and Chrome web extensions!
Connect to EC2 instances straight away
Managing Leapp with its CLI
Create your own Leapp plugin to customize the App functionalities from the template

All the covered access methods can be found here…

View on GitHub

Leapp is an Open-Source tool that aims to manage the credentials provider chain for you.

It uses short-lived credentials instead of hard-coded ones; it also removes them from the chain when not needed anymore.

To sum up, we have seen different use cases to solve missing credentials errors when using AWS SDK or CLI commands. If you have any questions, by any means, feel free to contact me or join our slack community.

Until next time, see you all 🙂.

Testing your Signature v4 Cognito authenticated API: an Insomnia Plugin

Alessandro Gaggia — Tue, 03 Nov 2020 14:47:40 +0000

Introduction

Nowadays, applications are made more and more with a serverless approach in mind. Developers strive to separate as much as possible front-end tasks and structures from back-end and vice-versa.

With this approach, the testing phase still remains extremely important, but sometimes due to several reasons, it becomes inconvenient for front-end and back-end teams to rely on each other for retrieving information useful for asserting their code.

There are several reasons for that: time constraints, different speed in development, working on several branches, etc. Also, in our case, two extra motivations contribute to making this task more tedious than what it should have been.

As said, we were transitioning to a Serverless approach, so no more View and Logic tied together in the same codebase.
We used and still use Cognito as a means of authenticating our user pools for different applications, and many APIs are protected and need user's authentication for that.

AWS Cognito is handy when it comes to creating authentication flows both for users and for APIs (especially with API Gateway), nonetheless without installing a library, mocking authentication with Signature V4 is no easy task for sure.

In the early stages of Leapp development, we, as a team, faced the same situation.

Part of a side-project involving a Serverless architecture, filled with AWS Lambda functions as the back-end, required constant testing, being its logic complex and touching several areas of the software.

Of course, this meant testing authenticated calls!

We needed access to the API (made with Lambdas) through API Gateway to make different integration tests: this would make the REST ajax API from a mocked front-end using Signature V4 for authenticating the calls themselves.

Usually, this is done quickly by regular Javascript/Typescript calls given you are using the suggested AWS SDK, but how you can do that when you need to mock your front-end in back-end tests besides calling it directly? We got a solution by exploiting Insomnia plugin feature and developing a system to integrate Cognito Authentication to Insomnia to allow back-end developers to test their logic by making API calls directly from the tool.

This enhancement allowed us to decouple our testing phases and reduce the urge to keep the two teams always aligned. This is especially important because, as stated before, usually back-end can develop faster than the front-end as it doesn't have to deal with UI composing.

Insomnia is a free cross-platform desktop application for making REST and GraphQL interacting with HTTP-based APIs. Insomnia combines an easy-to-use interface with advanced functionality like authentication helpers, code generation, and environment variables. It allows team collaboration, and it's a tool of choice by many big companies, including Netflix and Cisco.

Moreover, Insomnia is an Open-Source project, acquired by Kong, and this was a motivator for us in choosing it because of the same very nature that drives our application Leapp.

By using our integration, it is possible to do authenticated calls to APIs behind Amazon API Gateway with an authenticator enabled.

Plugin structure

Insomnia gives some pretty neat instructions on how they want a plugin project to be structured.

By following the reference on this page: https://support.insomnia.rest/article/26-plugins, we have created a new node.js project.

We took extra attention to having a package.json similar to the one provided below, and that points the key "main" to "./src/plugin.js" and have "insomnia" as one of the keys (this last part is essential to make Insomnia recognize the code as a plugin):

{
  "name": "insomnia-plugin-aws-cognito-token",
  "version": "0.11.0",
  "description": "Plugin for Insomnia to provide Cognito JWT token from AWS",
  "main": "./src/plugin.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Leapp Team",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "https://github.com/Noovolari/insomnia-plugin-aws-cognito-token.git"
  },
  "keywords": [
    "insomnia",
    "plugin",
    "AWS",
    "Cognito",
    "AppSync"
  ],
  "insomnia": {
    "name": "awscognitotoken",
    "description": "Plugin for Insomnia to provide Cognito JWT token from AWS"
  },
  "dependencies": {
    "amazon-cognito-identity-js": "^3.0.5",
    "aws-sdk": "^2.373.0",
    "crypto-js": "^3.1.9-1",
    "jwt-decode": "^2.2.0"
  }
}

Then create a directory src in the root folder and add a new plugin.js file. Inside the file we want a structure similar to this one:

/**
 * Example template tag that generates a random number 
 * between a user-provided MIN and MAX
 */
module.exports.templateTags = [{
    name: 'random',
    displayName: 'Random Integer',
    description: 'Generate random things',
    args: [
        {
            displayName: 'Minimum',
            description: 'Minimum potential value',
            type: 'number',
            defaultValue: 0
        }, 
        {
            displayName: 'Maximum',
            description: 'Maximum potential value',
            type: 'number',
            defaultValue: 100
        }
    ],
    async run (context, min, max) {
        return Math.round(min + Math.random() * (max - min));
    }
}];

Template tags in the "args" section are used to define input variables, and "async run" uses positional variables to get them and run some logic for the plugin. This is, of course, a simplification, and you can undoubtedly call another method external to the module exports to keep the code more maintainable, extensible, and clean.

How to install the Insomnia plugin

Installing plugins in Insomnia is so easy. You just have to go on the Preferences and select the plugin tab. Then type insomnia-plugin-aws-cognito-token in the field that shows up and select "Install plugin." You have correctly installed the plugin!

Plugin Setup

To make it works to your needs, go into Insomnia → Preferences: click on development in the top-left corner, and choose "Manage Environments"; a new window will open up to show your current environments. Following directives from the figure below, click in the right corner as shown to create a new JSON structure:

For each parameter, we need a key in the JSON file, representing one of the possible dynamic variables used by the Insomnia plugin. Create the necessary permits like in figure — keeping in mind that we needed all the parameters to exploit V4 signature, but this is not necessarily true for everyone; thus you can keep only AwsToken—.

To have access to our plugin's functionalities to insert the correct value for a variable, just start typing "Leapp", and by pressing cmd + space (mac users) or ctrl + space (Windows and Linux users), you'll have access to two features to choose from:

Leapp - AWS Cognito Token
Leapp - Signature V4

Once selected the plugin's name, this should become highlighted as shown in the figure, and, at that point, it's possible to click on it to have access to configuration parameters. Let's see those of Aws Cognito Token:

You'll be asked to insert parameters like "email" (or username), "password length" (needed to avoid Insomnia making a request for every password character), and another set of parameters retrievable from Cognito's UserPool.

If everything is set up correctly in Live preview, you'll see the token pre-calculated like in the figure.

Let's now see IAM's V4 signature parameters. Following again the previous steps, for the same environment, generate a new JSON object, create the keys, and associate the signature feature, then click on it and go to the following screen:

On this page, you'll have to set your AWS config and credentials' file path — our plugin defaults it to your home directory —.

Then we proceed in selecting the Signature V4 property we want to assign to our variable for Insomnia; this procedure must be repeated for Access Id, Secret Key, Session Token, and Region.

Once the setup is completed, it will be possible to do authenticated API calls by following this procedure:

First thing first, select AWS as a property for "Auth" as shown below:

Insert parameters as described below:

As a final step, we need to complete Cognito Authentication setting this parameter like in figure:

You'll have to add Content-Type property with value application/json and our CognitoToken parameter as a token-id, set in an environment with the previous steps.

Final testing

We are ready to test the call: if all parameters are defined correctly, and your session token is still valid, you can use "Send" to launch your request as we did in the image below to see the response object in the right part of the Insomnia screen.

Security Considerations

One significant consideration we made was being sure to get sensitive information like credentials from the AWS Credentials' file and not to add them directly from the plugin.

Moreover, we wanted the credentials' file to persist on the developer's machine only for the time strictly necessary to work with it.

That's why this plugin is not only a helpful tool for our Leapp software, but it also obtains advantages by using it in combination.

Leapp is our Open-Source software for managing credentials in a multi-cloud environment with a keen eye on security as it can create and delete sensitive information on the fly, avoiding having credentials stored on a user's machine when not needed.

Conclusions

In this article, we found the occasion to share with all the readers how an internal need can be the drive to create something useful not only for a particular team but also for the Developer community.

The topic of splitting as much as possible dependencies between front-end and back-end to increase efficiency and parallelism is always an important one, especially when it comes to testing and/or debugging complex functions.

As things evolved in times, the front-end is now more complicated than before, and sometimes it requires more coding time than the back-end, mostly if the back-end is done with a serverless approach; this difference can cause the inability of the front-end to serve back-end REST calls when needed.

Keeping that in mind, we developed this plugin to help us realize Leapp with more ease, and we sincerely hope that our experience can help anyone reading this article and maybe willing to participate in evolving the project even more being it Open-Source.

Until our next article, stay safe and try Leapp! 🙂