3rd Party IAM Access

I decided to take a 1-hour detour from my work on gethigby.com to write this brief post. I was in the process of integrating a friend's tool into my own workflow when I caught a somewhat serious anti-pattern in their application's integration workflow. It's not the end of the world, but a seasoned DevOps person is going to think twice before integrating the service until this feature is changed.

The anti-pattern is to hand an AWS Secret Access Key and Id to the third party. In the past, this was a common approach to solving third-party integrations, particularly in the earlier days of AWS when the AWS authentication system was less sophisticated. Today, however, it is considered an anti-pattern and generally a big no-no.

The security team at my previous employer would have really frowned on this since we had strict SLAs and commitments with banks. We were required to rotate our user keys regularly, and rotating secrets manually like this would have been problematic.

Here is the anti-pattern: (Do not do this):

1. The third-party app wants access to a small part of a user's AWS infrastructure.
2. The user goes into AWS and creates an IAM user.
3. The user creates a user with limited permissions.
4. The user grants said user, with limited permissions, API access to the AWS account.
5. The user generates a Secret Key and Secret Id.
6. The user copies and pastes Secret Access Key and Secret Access Id into 3rd party web form.
7. The third party uses Secret Access Key and Secret Access Id to access the user's AWS account.

Here are some scenarios where the approach mentioned above becomes problematic:

1. Six months after configuring: the third-party website with keys, the user needs to rotate keys and has to manually update them in the third-party account.
2. Keys can be leaked from the third-party server: i.e., SQL injection attack. The problem with keys is that they are essentially bearer tokens, which means anyone who has them can use them.
3. Data breaches happen all the time: Large companies are compromised all the time. It's not uncommon for companies to be targeted for vulnerabilities, especially companies like LastPass that are meant to store and hold secrets securely.
4. Reputation damage: If your AWS account is compromised due to shared keys, it could lead to negative publicity and loss of trust among your customers, partners, or stakeholders.
5. Non-compliance: Sharing keys with third parties may violate regulatory requirements or internal security policies, resulting in fines, penalties, or other consequences.
6. Difficulty in auditing and monitoring: When multiple third parties have access to the same keys, it becomes difficult to track and attribute actions to specific individuals or entities, complicating auditing and monitoring efforts.

So what is the solution?

One solution is to grant the third-party account limited access using an IAM role instead of a key. In this scenario, even if the role name and details are leaked, it's not a big issue unless the actor attacking the third party actually takes over the third party's servers, which is a larger and more precarious attack. It's much harder to go unnoticed in that type of attack and it is slower because, the attacker would have to remain on the compromised servers to attack a specific target.

Here is the trust policy a user would need to set up to grant a third party access:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<3RD_PARTY_ACCOUNT_ID>:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "ad235b04c871250478b9048b7a553cdc188aa1686c5fb995014012f3cd40ce39"
                }
            }
        }
    ]
}

This policy allows the third party to assume a role that you define, which has only the necessary permissions to access the specific resources needed. By using this method, you can ensure that your AWS resources remain secure and that your sensitive data is protected from unauthorized access or exposure. Additionally, using IAM roles instead of keys simplifies the process of rotating access keys and ensures that your security measures are always up to date.

For more info I found this great video by Cloud Bart. I need to get back to work ;)