I could not disagree more re. the expiring credentials. It is a bad practice to have credentials that never expire, especially on developer laptops, especially credentials of this nature. Developers frequently store this stuff in plain text in their home directory or as environment variables. That's a huge security risk! This service manages the process of generating and expiring credentials automatically, which is awesome.
This service is for code artifacts. What credential to the developers use to access source code? Do they expire?
It is common for developers to use Git to store source code, in a hosted service like GitHub. It is common to use SSH keys to access Git. Frequently those SSH keys are generated without passphrases. Those are non-expiring credentials stored on disk. If HTTPS is used to access Git, it will likely be with non-expiring credentials.
I'm not saying short lived credential are bad, not at all. I'm pointing out how this service differs from similar services, requiring a change it workflow, which might be annoying to some people. Not everyone is operating under the same threat model.
Your source code may reference a shared library at a specific version from a trusted source to build. This trusted source is CodeArtifact.
The short lived passwords is a non issue and a good thing. Your dependency resolver should handle fetching the new password and most orgs I’ve worked at had scripts dealing with short lived passwords/iam.
> Your dependency resolver should handle fetching the new password
According to AWS's documentation, none of the supported dependency resolvers will fetch the new password[1][2][3].
If they were capable of automatically fetching the new password without human intervention, it would mean they have credentials for generating credentials. If this isn't on an EC2 instance (where an IAM role can be used), that means there are long-lived credentials (probably written to disk) used to generate short-lived credentials.
This would be the case if you are using a hosted CI service that doesn't run on your own EC2 instances. You would probably be providing an AWS key and secret, which would then be used to generate the short-lived credentials. But the key and secret won't be short-lived, and will have at least the same access as the short-lived credentials (probably more access).
> Your source code may reference a shared library at a specific version from a trusted source to build. This trusted source is CodeArtifact.
HTTPS is what forms the trust between you and the artifact repository. Short-lived passwords don't do anything to ensure you are talking to the real trusted source. They may make it so the artifact repository can better trust you are who you say you are, but I don't see what they has to do with safely getting a specific version of a library.
> that means there are long-lived credentials (probably written to disk) used to generate short-lived credentials.
In terms of local development experience, most mature organizations will have these "long lived" credentials still require an MFA at a minimum of once per day and locked down to particular IP addresses to be allowed to get the temporary credentials.[1]
> This would be the case if you are using a hosted CI service that doesn't run on your own EC2 instances.
Typically you'd want to see third-party platforms leveraging IAM cross-account roles these days to fix the problem of them having static credentials. Granted, many of them are still using AWS access key and secret.
This is still not a "solved" area though, and a point of concern I wish would get more aggressively addressed by AWS.
> I could not disagree more re. the expiring credentials. It is a bad practice to have credentials that never expire, especially on developer laptops, especially credentials of this nature.
For the specific use case of the developer box and the Docker registry, resetting the credentials every 12 hours doesn't offer any more security than not on its own.
The reason for that is after you try to login to ECR after the expired time, the way you authenticate again is to run a specific aws CLI command to generate a docker login command. After you run that, you're authenticated for 12 hours.
If your box were compromised, all the attacker would have to do is run that aws command and now they are authenticated.
Also, due to how the aws CLI works, you end up storing your aws credentials in plain text in ~/.aws/credentials and they are not re-rolled unless the developer requests to do so. Ultimately they are the real means for Docker registry access.
Those credentials sitting in ~/.aws/credentials should also expire after 12 hours. There are plenty of tools out there to automate this process so you just log in with Okta or similar tool in your CLI and your done (bonus they also make switching between accounts a lot easier).
There is absolutely no reason with the tools that we have available that we should be creating long living AWS keys. It's a major security risk if those keys ever got out.
> Developers frequently store this stuff in plain text in their home directory or as environment variables
If you care about the security of these artifacts, why is their home directory (or their full disk) not encrypted? If they have access to the repository, they probably have artifacts downloaded on their laptops, so if the laptop is compromised, the artifacts are compromised anyway.
Edit:
Not saying temporary credentials are bad. But the reasons you gave seem a little suspect to me. A better reason is that you don't have to worry about invalidating the credentials when an employee stops working for you.
The problem isn't encryption, let's assume everyone has full disk encryption turned on, so someone who steals your laptop can't access your data.
The problem is that your home directory is accessible to a ton of apps on your computer, and you have no idea what each of them is doing with that access. You also have no idea if any of them can be / are being exploited. The most recent case being Zoom – if that server they had running on localhost and responding to anyone on the laptop had file system access APIs (which is reasonable if Zoom had offered file sharing on calls) an attacker would have been able to read all your credentials.
If you have an app on your computer that is controlled remotely you have _massive_ issues. Creds are stored for SSH, browser, probably heaps of other things too. If this is a serious security concern within your threat model you should be auditing every single package or isolating (docker, vms, Bare metal if you’re super tin foiled), anything short of that is fake security.
>Creds are stored for SSH, browser, probably heaps of other things too.
And ideally these credentials should have similar controls applied around them as well (only temporary, using passwords to unlock the SSH keys, etc). If you don't have that, that's your choice, but just because some of your credentials lack security controls is not a reason for other credentials to lack security controls, too.
> you should be auditing every single package or isolating (docker, vms, Bare metal if you’re super tin foiled), anything short of that is fake security.
Which is exactly the reason that many orgs do specifically audit every package and disallow unapproved software. But again, even if some of your desktop apps are allowed unaudited, that is not reason to lessen your security elsewhere.
There’s a very limited set of scenarios where local file read isn’t accompanied by enough write/exec privilege to inject a keylogger. Sir, there might be some cases where the control would prevent abuse but they’re limited. IMO time/money should be invested in other security over anything more unless you’re literally nearing an absolutely secure environment. In most cases I’ve seen there’s gaping holes while crazy amounts of time and money are spent securing something that doesn’t actually improve overall security much or at all.
