AWS CodeArtifact: A fully managed software artifact repository service (opens in new tab)

Github already released their package repo last year (and have since purchased NPM). If anything I imagine that had Artifactory pretty scared vs. this. If your company already uses GitHub it's a hard sell to say why you'd need something like Artifactory over the Github package repo.

Meta: I’ve vouched for your killed comment. I suspect you may be shadowbanned.

For maven, to push artifacts via the correct mvn deploy:deploy-file requires a S3 wagon (transport layer) software to actually make the S3 calls. For bigger orgs, having everyone use a wagon is a non-starter.

All I'm seeing this does is give the proper http endpoints so you dont need the wagon. Is it worth ~2x the price, no, but it's better than the other enterprise-y solutions.

It looks like the SLAs are about the same (https://aws.amazon.com/s3/sla/ and https://aws.amazon.com/codeartifact/sla/). I haven't seen any documentation on garantees for performance for either service, but I'm skeptical this will perform any better than s3.

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.

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

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

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.

I think mainly the ease of having security dealt with around who can access etc really. Ofc you can just upload files and serve them over http, but I'd like something that's as easy to setup and use as nexus for these files - and something that forces a structure for how they are organised. Stops arguments and people doing whatever they want.

It’s nice having the metadata around the push available versus raw blobs to s3.

Very large c++/python/cuda application that is packed into various different images (squashfs images, but functionally the same).

We end up having a lot of libraries that are shared across multiple images.

Intermediate packages permit you to choose different deployment situations later, with minimal additional cost now. Tying everything to Docker images ties you to Docker and removes your ability to transition to other systems. It may not be worth the cost now, but as soon as you want to deploy on more than one platform it can become critical to maintaining momentum (vice having to hand tailor deployment for each new environment).

sounds surprisingly manual. has AWS not tried to formalize some sort of feature voting system?

My guess (purely a guess though) is that this is a good proportion of the platforms AWS use internally, and that this service will expand to other ecosystems less used internally in response to customer demand.

Static feeds are much slower than one that use a real server.

yep. I've worked on a solution that "just uses s3". It is not trivial.

I still don't see what's different. I can configure pip to look at my git server, so that all I have to do is `pip install my_thing` and it will automatically download all public and private deps. I don't know what you mean by "workflow" in this context but this is just about as simple as can be.