5 ms·

The login credentials expire after 12 hours (or less)[1], just like with their Docker registry (ECR). That makes it pretty annoying to use, especially on develo

The login credentials expire after 12 hours (or less)[1], just like with their Docker registry (ECR). That makes it pretty annoying to use, especially on developer laptops. GCP has a similar offering[2]. And GitHub[3]. [1] https://docs.aws.amazon.com/codeartifact/latest/ug/python-configure.html https://docs.aws.amazon.com/codeartifact/latest/ug/python-co... [2] https://cloud.google.com/artifact-registry https://cloud.google.com/artifact-registry [3] https://github.com/features/packages https://github.com/features/packages

toomuchtodo 6y ago
You should have a shell alias to rapidly top up your auth token, just like with the Docker ECR. Short lived tokens are best practice, and a 12 hour TTL is reasonable. That’s no more than two auths in a day as a dev.
- antoncohen 6y ago
  And every developer needs to have that alias. And all automation needs to be changed to call that command before trying to use pip, or mvn, or whatever. It sucks. No other hosted artifact repository does this.
  - toomuchtodo 6y ago
    It’s roughly a dozen lines of bash (error handling and all), speaking as someone who has had to maintain dev tooling for an org where Docker ECR was used, and can be checked into your project’s repo. It’s not onerous at all, either on devs or your build and deployment pipelines/runners.
  - cle 6y ago
    If only devs had a way to share code with one another...
deleted 6y ago
[deleted]
blaisio 6y ago
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.
- antoncohen 6y ago
  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 6y ago
    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 6y ago
      > 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-configure.html https://docs.aws.amazon.com/codeartifact/latest/ug/python-co... [2] https://docs.aws.amazon.com/codeartifact/latest/ug/npm-auth.html https://docs.aws.amazon.com/codeartifact/latest/ug/npm-auth.... [3] https://docs.aws.amazon.com/codeartifact/latest/ug/env-var.html https://docs.aws.amazon.com/codeartifact/latest/ug/env-var.h...
code4tee 6y ago
Can’t imagine any serious tech environment still allowing non-temporary creds. If they do, good luck when the security audit happens.
kccqzy 6y ago
Why so? You just log in once a day at the beginning of your work day. I don't think you'll work a 12-hour day so that should be good for the entire day.

toomuchtodo 6y ago

You should have a shell alias to rapidly top up your auth token, just like with the Docker ECR. Short lived tokens are best practice, and a 12 hour TTL is reasonable. That’s no more than two auths in a day as a dev.

antoncohen 6y ago
And every developer needs to have that alias. And all automation needs to be changed to call that command before trying to use pip, or mvn, or whatever. It sucks. No other hosted artifact repository does this.
- toomuchtodo 6y ago
  It’s roughly a dozen lines of bash (error handling and all), speaking as someone who has had to maintain dev tooling for an org where Docker ECR was used, and can be checked into your project’s repo. It’s not onerous at all, either on devs or your build and deployment pipelines/runners.
- cle 6y ago
  If only devs had a way to share code with one another...

deleted 6y ago

[deleted]

blaisio 6y ago

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.

antoncohen 6y ago
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 6y ago
  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 6y ago
    > 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-configure.html https://docs.aws.amazon.com/codeartifact/latest/ug/python-co... [2] https://docs.aws.amazon.com/codeartifact/latest/ug/npm-auth.html https://docs.aws.amazon.com/codeartifact/latest/ug/npm-auth.... [3] https://docs.aws.amazon.com/codeartifact/latest/ug/env-var.html https://docs.aws.amazon.com/codeartifact/latest/ug/env-var.h...

code4tee 6y ago

Can’t imagine any serious tech environment still allowing non-temporary creds. If they do, good luck when the security audit happens.

kccqzy 6y ago

Why so? You just log in once a day at the beginning of your work day. I don't think you'll work a 12-hour day so that should be good for the entire day.