Forem: John McCracken

AWS IAM Roles Anywhere Demo

John McCracken — Sun, 24 Aug 2025 19:00:20 +0000

Introduction

IAM user access keys are the normal way to access AWS from an external source. Generally this is the method to use for machine/code access to your AWS estate.

This is ok, but come with some issues:

Long lived credentials expand the window of opportunity for an attacker to exploit the access key.
Rotating secrets can be hard to manage; synchronising credentials rotating with third parties can be complex.
It just doesn't scale, anything over a handful of access keys becomes hard to manage.

The AWS preferred solution is to use AWS IAM Roles Anywhere for workloads outside of AWS.

Short term rotating credentials
Uses industry standard X.509 certificates
Reduces management complexity

Although a bit more complex to set up, AWS IAM Roles Anywhere is a much more elegant, scalable solution for workloads. It also ticks all current AWS security best practices.

How does IAM Roles Anywhere work?

Workloads use SSL Certificates (end-entity certificate) which have been signed by a Certificate Authority (CA). The CA can either be external or provided by AWS.
Create a Trust Anchor between IAM Roles Anywhere and the CA
Create a Profile, which defines the IAM policy to apply after successful authentication

Be aware that although IAM Roles Anywhere is free, if you use AWS Private CA there will be a cost, it’s around $400 per month! I believe you can cancel within the first 30 days free of charge.

In this demo, I’ll stick with a free external self generated one. Its a bit of a pain to generate, but hopefully this demo makes it as painless as possible.

What this guide intends to do

Generate an external CA
Generate an end-entity certificate which is signed off against the CA.
Setup a IAM Roles Anywhere Trust Anchor with the CA certificate
Setup a IAM Roles Anywhere Profile and link a IAM Policy
Setup a local machine to use aws_signing_helper in an AWS Profile.
Demonstrate it works with AWS CLI and Python/boto3. ##Setting up IAM Roles Anywhere

I’ve tried to script as much as possible, that way you can get it running as quickly as possible and it still offers the full details for those who want to dig deeper under the hood.

I’ve created a repo for all this goodness: aws-iam-roles-anywhere-public-demo

This contains the following:

Shell script to generate CA and end certificates
Terraform to deploy to AWS
Python example script to test access

All instructions are for Linux/MacOS. If you're using Windows, you've got bigger problems than trying to follow this blog.

Generate a Certificate Authority and a End Entity Certificate

On the CLI and clone the repo and go to the root directory. There is a bash script located here called create-ca.sh which can be used to automatically generate the required Certificates.

This uses a config file root-ca/root-ca.conf, you can use the default values or edit to suit your requirements.

Open the script create-ca.sh and have a look over what it's actually doing, the comments hopefully help clarify.

The certificates values are stored in root-ca.conf and client-ca.conf.

Once you're comfortable with the contents, run the script:

sh ./create-ca.sh

When prompted, select Y for any prompts.

You should now have the following created in the root-ca folder:

certs folder containing a CA .pem file
db folder with CA version data
private folder with a private key and certificate signing request file
clients folder with end-entity certificate key/pem file

This is all the files required to get started. Be aware this is all basic stuff and shouldn't be used in a production environment.

Note: this script copies the following files from the ./clients/ folder into your ~/.ssh folder:

~/.ssh/iam-roles-anywhere-demo.key
~/.ssh/iam-roles-anywhere-demo.crt

Please delete these manually afterwards.

Deploy the Infrastructure as Code

Feel free to deploy by click-ops, it's pretty self explanatory, but everything really should be IaC.

Make sure you have authenticated to the AWS account you wish to use, by pasting Access keys into the CLI or however you normally do it.

From the root directory, cd terraformthen

terraform init
terraform apply

Plan output should create the following:

aws_rolesanywhere_trust_anchor
Create a Trust Anchor, this connects IAM Roles Anywhere to the certificate.

aws_iam_role
This is the role used by IAM Anywhere, it has a condition that the certificate Common Name (CN) must be ‘IAM Anywhere Demo’.

aws_iam_role_policy_attachment
Attach the managed policy AmazonS3ReadOnlyAccess to the role

aws_rolesanywhere_profile
Create an IAM Roles Anywhere Profile called ‘iam-roles-anywhere-demo’. Note that the profile also is linked to the managed policy AmazonS3ReadOnlyAccess. The profile can set the maximum permission boundary.

For example, if I had attached AmazonS3FullAccess to the role, the Profile permissions would restrict S3 permissions to read only.

Check over the plan and if all looks good to you, type yes to deploy.

If all goes well, the resources should be deployed to your specified AWS Account.

The output should contain a key credential_process, copy the value for this key and paste it somewhere safe for now. This outputs the aws command required later to authenticate. It should be something similar to this:

credential_process = "~/.aws/aws_signing_helper credential-process --certificate ~/.ssh/iam-roles-anywhere.crt --private-key ~/.ssh/iam-roles-anywhere.key --trust-anchor-arn arn:aws:rolesanywhere:eu-west-1:ACCOUNTID:trust-anchor/880ee543-af45-48c7-b5cd-bf0b73e95059 --profile-arn arn:aws:rolesanywhere:eu-west-1:ACCOUNTID:profile/048f1bf7-da4c-41cd-99ed-ee6b93021297 --role-arn arn:aws:iam::ACCOUNTID:role/iam-roles-anywhere-demo"
profile-arn = "arn:aws:rolesanywhere:eu-west-1:ACCOUNTID:profile/048f1bf7-da4c-41cd-99ed-ee6b93021297"
role-arn = "arn:aws:iam::ACCOUNTID:role/iam-roles-anywhere-demo"
trust-anchor-arn = "arn:aws:rolesanywhere:eu-west-1:ACCOUNTID:trust-anchor/880ee543-af45-48c7-b5cd-bf0b73e95059"

Test AWS Access

If you want to view the resources in the AWS console, go to the IAM Dashboard, then Roles and then scroll to the bottom of the main window.

Firstly, AWS provide aws_signing_helper to simplify access, download and install, make sure its in your PATH.

You can use this file to retrieve short term credentials and then add them to environmental variables as you can with AWS IAM access keys, but I have found a better way is to update the ~/.aws/config file:

Open ~/.aws/config and create a new entry profile:

[profile iam-roles-anywhere-demo]

Now directly below this, paste the Terraform output mentioned previously, so it should end up something like this:

[profile iam-roles-anywhere-demo]
credential_process = aws_signing_helper credential-process --certificate ~/.ssh/iam-roles-anywhere.crt --private-key ~/.ssh/iam-roles-anywhere.key --trust-anchor-arn arn:aws:rolesanywhere:eu-west-1:ACCOUNTID:trust-anchor/880ee543-af45-48c7-b5cd-bf0b73e95059 --profile-arn arn:aws:rolesanywhere:eu-west-1:ACCOUNTID:profile/048f1bf7-da4c-41cd-99ed-ee6b93021297 --role-arn arn:aws:iam::ACCOUNTID:role/iam-roles-anywhere-demo
profile-arn = "arn:aws:rolesanywhere:eu-west-1:ACCOUNTID:profile/048f1bf7-da4c-41cd-99ed-ee6b93021297"
role-arn = "arn:aws:iam::ACCOUNTID:role/iam-roles-anywhere-demo"
trust-anchor-arn = "arn:aws:rolesanywhere:eu-west-1:ACCOUNTID:trust-anchor/880ee543-af45-48c7-b5cd-bf0b73e95059”

Now save and exit file

Note: You might need to replace /.ssh with the full path, in my case this was /Users/john.mccracken/.ssh

Testing with AWS CLI

aws sts get-caller-identity --profile iam-roles-anywhere-demo

{
    "UserId": "XXXX",
    "Account": "1234567890",
    "Arn": "arn:aws:sts::1234567890:assumed-role/iam-roles-anywhere-demo/00bc75fc5a6709cca9402a061453a2f3a9"
}

Then try

aws s3 ls --profile iam-roles-anywhere-demo

Testing programmatically with Python/boto3

In the python-iam-anywhere-test folder, there is a test.py file which will list buckets from the Account, there is a poetry.lock file with the required dependencies (boto3).

From the root directory, cd python-iam-anywhere-test then

poetry install
poetry run python test.py

This should list all S3 buckets.

Conclusion

IAM Roles Anywhere is a great elegant solution for external access to AWS resources. Setting up your own CA is a pain, but it's once done, the integration with AWS is pretty seamless and straightforward.

aws_signing_helper makes life really simple, if you want an idea of how complex the process is under the hood, check out the repo.

Now I have IAM Roles Anywhere setup, I intend to use it going forward rather than access keys.

Any feedback, please get in touch. I'd love to hear from you.

Additional links

Always standing on the shoulder of giants:

1Password CLI, AWS and Terraform

John McCracken — Thu, 02 Feb 2023 10:39:46 +0000

The issue

1Password CLI is great, having a single source for managing access keys and being able to use fingerprint ID on a Mac is such a cool feature. The AWS plugin works great, but if you want to use AWS through a third party (in this case Terraform), I failed to get it to work.

❕ This blog post is based on finding a MacOS solution, mileage may vary on other operating systems.

The plan

After some searching I came across this guide Storing AWS CLI Credentials in 1Password by Kenneth Falck. Its now outdated and didn't work for me, but it was more than enough to point in the right direction.

So firstly, setup everything:

AWS CLI
1Password CLI
1Password AWS plugin. ❕ I ignored Step 2: Source the plugins.sh file here as the alias it adds is no longer required.
jq tool

The solution

next, edit the ~/.aws/config file:

[default]
credential_process = sh -c "op item get '*1PASSWORD OBJ*' --format json | jq '.fields | map({(.label):.}) | add | {Version:1, AccessKeyId:."access key id".value, SecretAccessKey:."secret access key".value}'"

Amend the *1PASSWORD OBJ* name to the name of the 1Password access key entry.
If you followed the guides, the fields should be access key id and secret access key, if different, change accordingly.

credential_process allows you to load credentials from an external process.

To check it works, try aws iam get-user, if this works, try a terraform command.

Hopefully it works... 😬

Thanks to Kenneth Falck for initially solving this.

Isolating PHP with Docker Containers

John McCracken — Thu, 01 Nov 2018 20:30:41 +0000

Docker is a great piece of technology. It's a nice way to setup a development environment or experiment with new software without actually clogging up your own system.

I was messing around with serving some webpages using Docker with Apache and PHP. How could I easily switch PHP versions without clogging up my local machine or creating multiple Docker images/Vagrant boxes? I'm sure lots of developers could easily find a solution, but I must admit I do have trouble conceptualising container solutions. The layers of abstraction cause a mental block, I'm sure I'm not alone with this.

It struck me that Apache/PHP doesn't fit into the Docker one process per container doctrine. PHP and Apache as so glued together that in regard to separation of concerns, it's a non starter.

I really wanted my web server container to be isolated from the programming language. Switching to NGINX and PHP-FPM offers a much cleaner separation, which allows us to switch language versions with ease. This could be handy if you have legacy sites that require different versions or you want to try out a site before upgrading.

Setup

So the plan will be that when a request is sent to the test5.com/index.php url, the Nginx container will pass the request to process index.php onto a container running PHP 5 and obviously the equivalent for test7.com/index.php and PHP 7.

First things first, add 2 entries to the /etc/hosts file:

127.0.0.1 test5.com
127.0.0.1 test7.com

These will be the addresses we use to access the Nginx container.

Download or clone the repository from GitHub docker-php-isolation-example to a suitable place on your system. All commands will be ran from the CLI from within this folder.

The folder structure is relatively simple:

webroot - the self explanatory folder which contains a file called index.php which contains the phpinfo() command.
site.conf - Nginx site(s) configuration file.
docker-compose.yml - docker setup configuration file.

The docker-compose.yml file sets up 3 containers, all based on Alpine Linux image, so the total for the containers is a tiny 120Mb.

version: '2'
services:
    web:
        image: nginx:alpine
        ports:
            - "8080:80"
        volumes:
            - ./webroot:/var/www/html
            - ./site.conf:/etc/nginx/conf.d/site.conf
        links:
            - php7
            - php5
    php7:
        image: php:7-fpm-alpine
        volumes:
            - ./webroot:/var/www/html
    php5:
        image: php:5-fpm-alpine
        volumes:
            - ./webroot:/var/www/html

The main container is the Nginx proxy, which is the only container with an external port (8080). This container proxy's any valid requests to the two other containers, one running php 7 php-fpm, the other php 5 php-fpm on port 9000.

the webroot folder is shared between all 3 containers, Nginx needs this to serve any non PHP files, while the PHP containers need access to the PHP files.

The site.conf file contains defines how Nginx treats requests:

server {
    listen 80;
    index index.php;
    server_name test7.com;
    root /var/www/html/;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php7:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

server {
    listen 80;
    index index.php;
    server_name test5.com;
    root /var/www/html/;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php5:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

I'm sure theres a way to incorporate both of these addresses into one and use a regular expression, but lifes too short.

Running it

From the CLI, navigate into the folder where you downloaded the repository and type docker-compose up -d.

This will dowload the images if there not saved locally already and start the containers. Once finished type docker ps to make sure the 3 containers are running.

So open your browser of choice and type test5.com:8080 and you should see phpinfo() for PHP 5.

Next, type test7.com:8080 and you should see phpinfo() for, you guessed it, PHP 7!

And there you go, we can define which version of PHP to use to process the same index.php file, hours of fun...

Tidying up

Had enough excitement? To close down the running containers, type docker-compose down, this should close and remove the containers.

If you want to remove the downloaded images, type docker images and then docker rmi IMAGE ID, for example docker rmi 4fe1b7f08eb1 8b057b9de580 1b95155d2daf would remove the 3 images with IDs 4fe1b7f08eb1, 8b057b9de580 and 1b95155d2daf.

Finally

The concept of offering PHP as a kinda ‘Software as a Service’ might be a humble idea, but its something I find really cool. Being able to isolate versions of a programming language interests me greatly and might be something that I try and incorporate in future projects.

^{Isolating PHP with Docker Containers first appeared on my blog site on 07/10/2017.}

Automate AWS security group with CloudFlare IPs

John McCracken — Sun, 28 Oct 2018 20:31:56 +0000

I'm a big fan of Cloudflare. Even the basic free service offers numerous caching and security features which would be pretty time consuming to implement yourself. At the very least it offers a free and very easy ssl certificate service.

Security should always be thought of as a layered process and Cloudflare plays an important role as a first line of defence. The ability to block out malicious or suspicious requests before it even reaches your server is a great asset. Obviously this only works if Cloudflare is positioned in front of your server and requests are forced to go through Cloudflare's proxy.

For any bad guy worth his salt, its relatively simple to figure out the real IP address of the server and bypass Cloudflare. Your server is now more vulnerable and security is now down to your server skills, up to date software and coding best practices.

Therefore its pretty important to stop direct access to your sites by only allowing web access from Cloudflare IP addresses. This blob post will cover doing this in the Amazon Web Services environment:

Creating a Security Group
Assign Security Group to relevant EC2 instances.
Create A Lambda function to regularly retrieve Cloudflare's IP address list and update the security group.

If you don't use AWS, the theory is still sound and wouldn't take much tweaking to achieve the same though a cron service and iptables.

The Lambda code uses Python 2.7 and uses the Boto3 library to communicate with AWS.

The Lambda Python code is available from the github code repository. I'm relatively new to Python, so feel free to contribute and improve.

Create EC2 Security Group

Firstly create a Security Group and take note of the Group ID. This can be done through the AWS web interface:

Or from the command line:

aws ec2 create-security-group --group-name cloudflare-access --description "http(s) access from Cloudflare IPs only" --vpc-id VPC-ID-GOES-HERE

Keep a note of the Group ID as will use this as an environmental variable with our Lambda code.

Create a Lambda Function

As these IP addresses may change, we need some code to update them. As were in the AWS environment, we can easily do this from a Lambda function which we can run on a regular basis for next to nothing.

If your not familiar with AWS Lambda, its software as a service facility where you can place some code (C#, Java Python or Node) and you only pay for the time that the code runs. No need to maintain a server, just code, pure glorious code!

So heres the code repository for one I did earlier.

The required code is in the file cf-security-group-update.py. For those not familiar def lambda_handler(event, context): is the main function thats called when the Lambda is triggered. What happens from here should be self explanatory from the descriptive function names.

Select blueprint

From the AWS user interface, select new function and select Blank Function from the blueprint list.

Configure triggers

Next, set a Trigger by clicking on the blank square and selecting CloudWatch Events - Schedule.

You can set up your required CRON or defined rate from here. For now select Rate(1 day) to run this daily.

Configure function

Now give the Lambda a name, choose Python from the runtime list and then paste the contents of cf-security-group-update.py from the github code repository in the text area.

In the Environment variables section, add the following:

key: SECURITY_GROUP_ID
value: add your security group id here

key: PORTS_LIST
value: 80,443

add 80 or 80,443 dependant on if you want http and https added to the security group.

You may need to add a role in the Lambda function handler and role section. If so the only rule needed is:

"Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:DescribeSecurityGroups"
            ],
            "Resource": [
                "*"
            ]
        }
    ]

Set the Timeout to maybe 5-8 seconds.

Keep the rest of the default values, continue and review, once happy finish by clicking Create Function.

Test

Click the Test button and accept the defaults and the Lambda should hopefully work. The output should list the IP addresses added.

To check it actually did add them, go back into the EC2 section and check your cloudflare-access security group and hopefully it contains IP addresses. Try deleting some and running the Lambda again, it should replace them.

There you go, you now have a Lambda function that will run routinely and will update the specified Security Group with any new CloudFlare IP addresses, Done!

Issues

If it didn't work or you got error messages:

Cloudflare response error - for some reason the cloudflare API wasn't available.
Failed to retrieve Security Group - The Group ID used was incorrect.
If the Lambda times out, click in the Configuration tab and set the Timeout to a higher value, 10 seconds should be adequate.
Any other errors are probably due to the Security Role being incorrectly setup. Its Stack Overflow time!

Todo

Add IPv6 addresses
Remove old IP addresses

^{Automate AWS security group with CloudFlare IPs first appeared on my blog site on 04/04/2017.}