Mid 2018 AWS released IAM Boundary policies, and it was immediately clear why they existed and where we could use them. This year AWS announced Session policies, but unlike boundaries it was not as obvious why they were created and how to use them.
In this post I’d like to show how to use them in code and possibly how they could be used in the wild.
What does a Session policy do?
Session policies behave similar to Boundary policies, where they set the maximum permissions the user can have.
Imagine your user has full S3 and EC2 access from attached identity-based policies, and during the AssumeRole action we pass the S3FullAccess policy into the session. For the duration of the session the user will only be able to access S3 and will get an unauthorised error when trying to access EC2.
If we pass the RDSFullAccess policy into the session? This will completely “lock” the session since the user never had RDS permissions to begin with and there will be no overlap between identity-based policies and session policies.
Session policies does not grant access, but merely sets the maximum permissions allowed.
So why do they exist?
If you’ve worked with an AWS account that requires MFA, you would have had to get a session token that was generated using a MFA code. IAM does a check to ensure the current session was created using MFA, not just that the user has MFA enabled. Session policies extent this functionality, by allowing us to inject policies when the session is created.
In highly regulated industries, access to workloads can be very tightly controlled and depending on the workload, limited to a very specific set of conditions. A way I’d like to see us use Session policies is with tools like HashiCorp Vault, where token issuance can be tuned based on the time of day, are we in a change freeze, are certain services off-limit when the request was made?
How to use them?
I’ve created a simple python script to demonstrate how session policies can be implemented (see end of the post). First thing to know about Session policies is that they can only be applied during the AssumeRole action on STS. This is a bit of an inconvenience, I’d like to be able to apply this when getting a session token as well, so for this to work we need an identity that is allowed to assume a role.
For simplicity sake, create an IAM User and generate CLI credentials for the user. The user only needs sts:AssumeRole permissions;
Create a profile in you AWS CLI credentials file and chuck your access key and secret key in there;
Create a role, with a trust policy that allows your user to assume it and attach the S3FullAccess and EC2FullAccess policies to the role.
Test your credentials. Ensure you can assume the role and list S3 buckets and EC2 instances;
Install Python 2.7 and pip install boto3;
Run the script and pass in your role arn. The script will create a new entry in your credentials file with the restricted session token;
python index.js
Now try to do an EC2 describe instances, you should see something like this:
Unauthorised Error
Conclusion
On its own, Session policies have limited uses, but if used in a pipeline with other tools it can be extremely useful. I’m looking forward to see how people start using this and how this feature evolves over time.
Comments