Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to immutable identifiers #247

Closed
ejholmes opened this issue Mar 20, 2015 · 4 comments · Fixed by #1104
Closed

Move to immutable identifiers #247

ejholmes opened this issue Mar 20, 2015 · 4 comments · Fixed by #1104

Comments

@ejholmes
Copy link
Contributor

This is a ways off, but something to keep on radar. Docker 1.6 will support immutable identifiers. See moby/moby#11109

@ejholmes
Copy link
Contributor Author

ejholmes commented May 1, 2015

It would be nice if we could fast track this. Currently the sentence:

Empire doesn't enforce how you tag your Docker images

Isn't true, because we resolve the tag to the image id, then use that to create the slug. Removing this constraint means you can deploy any image that's in a docker registry, which is pretty awesome.

@ejholmes
Copy link
Contributor Author

ejholmes commented May 5, 2015

I spiked into this a little on friday. Turns out, the immutable identifiers are not very useful and difficult to actually use. If you pull an image by tag, you have no way of telling what the identifier is after the fact.

I think a better first step would be to just disable the resolving and caching for slugs. If I deploy remind101/acme-inc:latest then the new slug should just be created with the remind101/acme-inc:latest tag. This would work fine for us, since we'll always deploy with a git sha as the tag, which will work as our immutable identifier, and this will allow us to stop tagging images with the image id. The only downside is the extra time to extract the procfile if the image id has already been extracted, but I think that's a worthwhile tradeoff.

@ejholmes
Copy link
Contributor Author

Gonna close this as a wontfix for now, mainly because @sha256 isn't supported in ECS and this hasn't felt like a real problem.

@ejholmes
Copy link
Contributor Author

ejholmes commented Sep 1, 2017

I'm re-opening this, since it's now supported in ECS as of ~May: aws/amazon-ecs-agent#104 (comment)

I think this is pretty important from a security perspective, since digests solve various attack vectors like mitm attacks, or credential exposure of your registry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant