In this episode, Eoin and Luciano talk about how to manage AWS credentials and different ways to manage them. From the more traditional (and not recommended) IAM credentials to SSO.
In this episode we mentioned the following resources:
Published 2021-11-26 - Listen on your favourite podcast player
In this episode, Eoin and Luciano talk about how to manage AWS credentials and different ways to manage them. From the more traditional (and not recommended) IAM credentials to SSO.
In this episode we mentioned the following resources:
Eoin: Hello and welcome to another episode of AWS Bites, the weekly show where we answer questions about AWS in about five minutes. I'm Eoin and again, I'm joined by Luciano. And before I get started, make sure to give us a follow and a subscribe so you can be notified when the next episode goes live. And today's question is, how do you manage your AWS credentials? What do you think of Luciano?
Luciano: Yeah, this is really a big topic and I hope we are going to be able to summarize it effectively in the, with the time we have today. But I think we generally have to distinguish between two different scenarios. One is when you are a user, a person trying to access AWS and you can do that through the web console or you can do that through the CLI. And another one is when you are an application. So imagine like a service and you need programmatic access through the SDK.
The traditional way that you will get access to AWS, which is no longer recommended is basically that you go into IAM, you create a user, you create programmatic credentials for that user, that user has a role that allows the user itself to access different resources. And at this point you take those programmatic credentials and you use them to access AWS. Now why this is not recommended, first of all, it's not secure because the credentials are always the same until you revoke them. It's not particularly easy to rotate those credentials. So that discourages, I suppose, people from having good practices and rotating them often. And also they are very easy to steal because for instance, if you configure the AWS CLI, those credentials are just text in plain text in a file in your own directory. So it's very easy to grab them and use them for all sorts of purposes. So I don't know, what do you think would be a better alternative, Eoin?
Eoin: Yeah, so I suppose it depends on what we're actually trying to achieve. And for applications that are running on AWS, like in an EC2 instances or an ECS or in a Lambda function, AWS manages that for you. So you don't actually have to manage any credentials yourself. EC2 would use a metadata service and Lambda will inject temporary credentials for you. So you don't have to store and should not be storing any credentials there or any access keys.
But you might still need to manage credentials for external applications, things that aren't running in AWS. So they might be running on a third party SAS or on an on-prem system. And people have frequently used access keys and secret access keys for that in the past, but generally you don't need to do that anymore. There's alternatives there. So one example of that is, let's say you're building a CI CD and you're using GitHub actions.
With GitHub actions, you can use a Web Identity Federation and OpenID Connect to assume a role from your GitHub action. And you don't have to do any credentials storage in GitHub. So you don't have to worry about long lived credentials in secrets in GitHub and the possibility of those being leaked as you build your application. So I think it's great that we're moving away from the ability to store these really dangerous access keys all over the place. That's for kind of application access. So let's go back to user access. What do you think we can use instead of IAM users? What are the options there?
Luciano: Yeah, there are a few things I've seen in the past to try to protect a little bit more of those credentials. One is using MFA. With MFA, you can basically create a user with a role that is very restricted. The only thing that it can do is assume another role. And in the policy that allows you to assume that role, you can put a condition that says you can do that only with MFA. So that adds another layer of security, even if the credentials are stolen, then you still need that MFA token to be able to do anything useful with those credentials.
So that is, I think, a good enough solution for starting. There is an article from AWS that describes how to enable all of that. We're going to put it in the description. Another thing that I've used in the past is something called AWS Vault. It's a third-party utility that you can find on GitHub, and we're going to provide the link as well. And that one basically allows you not to keep the credentials in clear text in your system. So as a developer, you are going to store the credentials in the system keychain, which should be a little bit more secure. And then there is a CLI tool that allows you to extract these credentials only when you need them. And it also exposes a mock metadata API. So when you are developing, you can still interact seamlessly using the SDK from your machine. So that actually works really well. But again, I suppose there is a need of moving away from IAM entirely. So I don't know if you have any suggestion about that.
Eoin: Oh, yeah, definitely. I mean, the way to go for moving away from IAM users is to put AWS SSO in place. And this has all sorts of great benefits. It works really well from a developer user experience point of view. It's just much easier to manage users' permissions, groups, assignments. With SSO, it gets rid of a lot of the drawbacks you have with IAM users and access keys. It also allows you to use your existing identity provider.
So if it's Active Directory or Okta or even Google Workspaces, you can use those as your identity source. And then manage permission sets within SSO, assign groups, and ensure that credentials are short-lived. So that's really where it shines in comparison to users. With SSO, you always get short-lived credentials that will expire within like one to eight hours or up to 12 hours, I think. So SSO is really the way to go.
And there's good tooling around this. Now, there are still some gotchas. So if you're logging on to the web console, SSO works really well and makes it really seamless. If you're using programmatic access, so from the CLI or from one of the SDKs, there's a little bit more to it because not every SDK version supports the SSO process really well. So that's a little unfortunate. But until those things have come up to speed, there are some really good tools.
And Ben Kehoe, who's an amazing expert in the space of SSO, has put together some really good tools, which I use on a daily basis. One is AWS SSO util, which is just adds a lot of nice gloss on top of SSO for the CLI. And it allows you to populate all of the roles available into your config file, for example. If you're using things like the serverless framework or the CDK, they don't support SSO for the reasons I outlined because they're using the JavaScript SDK version two, which doesn't support it fully.
Ben has another tool called AWS Export Credentials, which is like a shame that allows you to just provide credentials as environment variables or somewhere else that you can use. There's still short-lived credentials. It adds a little bit more friction, but it means you're still able to get the best of both worlds and use SSO with those tools. So I know a lot of people have asked us to cover SSO on the podcast. So we're definitely going to come back and talk about SSO and all of the details around it in more detail. But I think as regards credentials, we've covered most of the main topics there. So that's all we've got for today. But if you want to find out about more of this stuff in future episodes, subscribe to the channel and do give us comments as well and give us a thumbs up. And we always like to hear your feedback. So thanks very much for that. And we'll see you next time.