[antoncohen]

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.

[tiew9Vii]

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.

[antoncohen]

> 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.

[1] https://docs.aws.amazon.com/codeartifact/latest/ug/python-co...

[2] https://docs.aws.amazon.com/codeartifact/latest/ug/npm-auth....

[3] https://docs.aws.amazon.com/codeartifact/latest/ug/env-var.h...

[shortj]

> 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.

[1] https://github.com/trek10inc/awsume, https://github.com/99designs/aws-vault, and a few other tools make this much easier to deal with locally.