How/Why OIDC works at LocalOps for AWS access

Until yesterday, we were accepting IAM access key and secret key to connect to AWS accounts.

LocalOps no longer accepts IAM access keys now. We switched to using OAuth 2.0 protocol/Open ID Connect and Role-based access to connect to AWS. Checkout announcement post for more details.

Problem with IAM keys

Traditionally, to enable tools (like LocalOps) to connect to cloud accounts, one can generate and share access keys, say in AWS - AWS Access key and AWS Secret key. These keys belong to an IAM user who is given specific permissions via an IAM policy to do specific operations within the AWS account. These keys can then be used inside AWS SDK to start making API calls to the corresponding AWS account to provision infrastructure, create EC2 instances or perform any other operation.

Keys can be stolen or leaked. Keys can be used by anyone as long as they hold them, they will be allowed to make calls to the AWS account. When keys live for long term, it increases the probability of someone finding and mis-using those keys.

Key rotation may mitigate these risks. Security frameworks like SOC2 recommend this process in general. Account owners can delete the old keys and generate a new key pair regularly, to ensure old keys don't work even if they were leaked in the past.

But then, key rotation doesn't happen on time when there are more connected systems and more personnel involved. When connecting to automation tools, they have to seamlessly support new keys. When doing private deployments to customer cloud environments, more IT teams/personnel from more than one org are involved which in turn would delay the rotation process.

We started out with this method in LocalOps of asking IAM keys to simplify things to start with. We encrypted them before storing in DB to handle these extra-safe. Our code decrypted the keys before using them every single time. But then we promised to get back to this area to tighten things up, because we knew keys are long living and not many are comfortable in giving out their AWS IAM keys to 3rd party tools like us due to its drawbacks.

What if..

What if two connected systems have a prior trust with each other, and generate short term keys just in time during access and invalidate them when operations are done?

Enter AWS Role based access:

AWS provides trust-based access via IAM Roles and recommends everyone to use it in place of IAM Keys.

One IAM user / identity from a source/trusted AWS account (say LocalOps's AWS account) can be set up to assume a IAM Role inside the target AWS account and generate short term access keys to access the target AWS account. These keys are deleted by AWS after a short period of time and thus increasing the safety by a LOT.

But, to do this, one has to use an identity/IAM user in the source AWS account and "that" identity/IAM user would in turn need IAM keys to authenticate itself inside the source AWS account. These source IAM accounts and their IAM keys can still be vulnerable to theft or leak, unless rotated regularly.

At LocalOps, we wanted to pick an access method where...

• no long term IAM keys are involved in the entire chain of access

• for those other keys involved in authenticating identities in source account, there has to be an automated process to rotate old keys without manual intervention or have a way to hide them deeper in sand so that it is super duper hard to find/use them meaningfully.

• the trusted identity server has to cloud-agnostic because LocalOps can connect to cloud providers other than AWS too, say Azure.

Enter OpenID connect (OIDC) and Role-based access:

We switched to using industry standard OAuth 2.0 protocol/Open ID Connect and Role-based access to connect to AWS accounts from today.

It still uses AWS Role based access. But the source identity is not an "AWS identity". It is instead a generic web identity originating from a OAuth 2.0 Identity server.

Here is how developers can connect their AWS account with LocalOps using OIDC. Developers can..

1. Establish a prior trust with LocalOps Web Identity server inside their AWS account. They can do this by creating a new OIDC provider (representing LocalOps Identity server) inside the target AWS account.

2. Setup a new IAM role to represent identities coming via the OIDC provider / LocalOps Identity server.

3. Setup a new IAM policy with necessary permissions and attach it to the IAM role to give appropriate permissions to those identities.

We have automated all the above steps in a cloud formation script and kept them readily accessible for our users to complete the connection in 1-click. Checkout Connections > New Connection workflow in LocalOps account (Sign up now for free).

LocalOps code will then be able to

• Authenticate at LocalOps OAuth 2.0 Identity server and get a short lived access token.

• Use the same identity/access token to connect to the target AWS account via the IAM role using AssumeRoleWithWebIdentity method

• And get a pair of short term IAM keys for accessing the target AWS account

These short term AWS keys will be deleted automatically by AWS after a pre-defined set of time.

Works on any cloud:

Benefit of OAuth 2.0/OIDC method is that it doesn't need an AWS account to act as trusted account nor have any associated IAM user/IAM key in the process. LocalOps can connect with any cloud provider / any service as long as they support OAuth 2.0 and OpenID connect protocol. Major cloud providers like Google Cloud and Azure supports them. Great! We can setup connections with them in similar strong fashion.

Works for both Public SaaS and Private SaaS deployments:

This works for scenarios for both Public SaaS deployments where devs connect their AWS account to deploy apps. They can have peace of mind knowing that they haven't shared long term access keys with LocalOps.

It works the same way for Private SaaS deployments where developers ask to connect their end customer cloud accounts with LocalOps without asking them to share IAM keys.

Easy/fast trust:

AWS account owners have less work in securing our access. They could be developers connecting their AWS account or the end customers of developers who are connecting to get a private deployment from developers. This builds trust pretty quickly.

~

Our authentication strategy need not work exactly the same way for you or your setup. We shared these details to show different methods to authenticate into AWS and how we evaluated them all for our concerns.

Get Started With LocalOps:

If you are trying to setup/configure your AWS account to setup up your production environment, you can skip all this analysis and rely on LocalOps to bring up your production environment in minutes! Sign up for our forever plan now.

If you need a personalised demo, you can book it from our website here at https://localops.co.