Answers: <p>Google Container Registry is a potential option.</p>
  
  <ol>
  <li>Registry is private</li>
  <li>Image layers are stored on a Google Cloud Storage bucket, which is encrypted by Google (RSA) and can be additionally encrypted with a client key (RSA)</li>
  <li>Access control is granular down to each individual object stored on GCS bucket</li>
  <li>Client-side authentication is enforced via oauth2. Clients configure docker to use the google cloud sdk as a credentials manager</li>
  <li>Images are pulled via ssl connections</li>
  </ol>
  
  <p>The fact that the registry is part of Google's Cloud Platform also means you can build up to some other interesting things. For example, you could set up a VM to serve as reverse-proxy and set up the GCP firewall to only allow 443 from a certain set of IPs (like your clients' offices).</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-05-25T20:02:54.443Z
Answers: 2018-05-25T20:02:54.443Z
Answers: tazer84
Answers: <p>Have a look at <a href="https://github.com/Senetas/crypto-cli" rel="nofollow noreferrer">https://github.com/Senetas/crypto-cli</a> </p>
  
  <p>It allows you to encrypt/decrypt containers when pushing and pulling from a public or private repo.</p>
  
  <p>(Full disclosure I know the guy who wrote it)</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-09-24T01:46:38.543Z
Answers: 2018-09-24T01:46:38.543Z
Answers: Rubblesink
Body: <p>We are developing and building docker images in our intranet, and need to deploy them to several hosts belonging to us (developers, internal testing, external testing and so on). Some of these are in our intranet, some are accessible for 3rd parties on the internet.</p>
  
  <p>The final deployment is inside the customer's intranet on several nodes (production, different test stages). These are behind firewalls that don't regularly let them access things outside their intranet, i.e., while some of them can be allowed to access an external registry for deployment, others can't and images have to be delivered manually through some arcane software upload tool.</p>
  
  <p>I am looking for a way to have a registry on the internet (possibly ran by ourselves on some VM out there, preferably not) which allows the images to be stored encrypted (preferably GPG or similar, not a simple password). But then also being able to rather simply delivering "half" of the stuff via some upload mechanism manually. The customer is very paranoid, so keeping the end-to-end-encryption up is quite important.</p>
  
  <p>Is there a tool that springs to mind, which is perfectly able to handle it? One solution would be to mirror the full registry to the customer premises on a dedicated host, keeping the encryption part intact.</p>
  
  <p>A "standard" solution would be great, I'd be loath to hack something together if there is something lean/lightweight/established/stable around, already.</p>
  
  <p>EDIT (+edit to the title): An extensive permission scheme like the one offered by Portus is a good start, but I am looking ideally for end-to-end encryption of the actual images. The customer is ultra paranoid and just getting started with Docker, cloud-based services etc.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-05-02T18:39:29.190Z
Comments: https://stackoverflow.com/q/37584961/2777965
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-05-02T19:29:33.413Z
Comments: Thanks, @030. That question you linked considers hiding the stuff from the eye of users; my question is about hiding it from people along the way (i.e., I don't need encryption *at* either end, only when transferring it through some registry).
Comments: AnoE
Comments: CC BY-SA 4.0
Comments: 2018-05-02T19:40:03.843Z
Comments: Ok. So basically you are looking for SSL for a docker registry like https for a website?
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-05-02T21:21:31.397Z
Comments: @030, as given in the question, `I am looking for a way to have a registry [...] which allows the images to be stored encrypted (preferably GPG or similar, not a simple password).`
Comments: AnoE
Comments: CC BY-SA 4.0
Comments: 2018-05-02T21:36:09.247Z
Comments: https://github.com/moby/moby/issues/23200
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-05-02T21:36:49.767Z
Comments: https://serverfault.com/a/894975/215599
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-05-02T21:39:41.333Z
Comments: Perhaps you could file an issue in the github tracker of docker? Sorry I tried to help, but I cannot find an answer either. Apart from that I will upvote the question.
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-05-02T21:56:48.850Z
Comments: Yeah, no problem @030, and thanks for the help. I guess not every question has an answer, especially if it's about a feature a software simply does not have (yet?). ;)
Comments: AnoE
Comments: CC BY-SA 4.0
Comments: 2018-05-03T05:25:19.247Z
Comments: @AnoE if I may ask what is that in the images you try to protect? I had a use case where separate files (data and/or custom software artefacts) needed to be protected, so we used standard encryption/decryption (encrypt on build - decrypt on run). All the other parts are imho not worth to be protected. Not exact answer to your question but I find myself what is the business problem you need to solve.
Comments: Ta Mu
Comments: CC BY-SA 4.0
Comments: 2018-05-03T05:57:28.627Z
Comments: @PeterMuryshkin, nothing special, just the application (no secrets, no data). It's one of those customers who prefers not to have their stuff outside of their ("physical") intranet unencrypted. You know, large, ex-government...
Comments: AnoE
Tags: <docker><deployment><encryption>
Title: Encrypting docker images (end to end); transporting over offline channels
UserDisplayName: AnoE
ThreadText: # Encrypting docker images (end to end); transporting over offline channels
  
  (Asked by: username_0 on 2017-09-03)
  
  We are developing and building docker images in our intranet, and need to deploy them to several hosts belonging to us (developers, internal testing, external testing and so on). Some of these are in our intranet, some are accessible for 3rd parties on the internet.
  
  The final deployment is inside the customer's intranet on several nodes (production, different test stages). These are behind firewalls that don't regularly let them access things outside their intranet, i.e., while some of them can be allowed to access an external registry for deployment, others can't and images have to be delivered manually through some arcane software upload tool.
  
  I am looking for a way to have a registry on the internet (possibly ran by ourselves on some VM out there, preferably not) which allows the images to be stored encrypted (preferably GPG or similar, not a simple password). But then also being able to rather simply delivering "half" of the stuff via some upload mechanism manually. The customer is very paranoid, so keeping the end-to-end-encryption up is quite important.
  
  Is there a tool that springs to mind, which is perfectly able to handle it? One solution would be to mirror the full registry to the customer premises on a dedicated host, keeping the encryption part intact.
  
  A "standard" solution would be great, I'd be loath to hack something together if there is something lean/lightweight/established/stable around, already.
  
  EDIT (+edit to the title): An extensive permission scheme like the one offered by Portus is a good start, but I am looking ideally for end-to-end encryption of the actual images. The customer is ultra paranoid and just getting started with Docker, cloud-based services etc.
  
  **Tags:** docker, deployment, encryption
  
  > **Comments:**
  > **username_1**: https://stackoverflow.com/q/37584961/2777965  
  > **username_0**: Thanks, @username_1. That question you linked considers hiding the stuff from the eye of users; my question is about hiding it from people along the way (i.e., I don't need encryption *at* either end, only when transferring it through some registry).  
  > **username_1**: Ok. So basically you are looking for SSL for a docker registry like https for a website?  
  > **username_0**: @username_1, as given in the question, `I am looking for a way to have a registry [...] which allows the images to be stored encrypted (preferably GPG or similar, not a simple password).`  
  > **username_1**: https://github.com/moby/moby/issues/23200  
  > **username_1**: https://serverfault.com/a/894975/215599  
  > **username_1**: Perhaps you could file an issue in the github tracker of docker? Sorry I tried to help, but I cannot find an answer either. Apart from that I will upvote the question.  
  > **username_0**: Yeah, no problem @username_1, and thanks for the help. I guess not every question has an answer, especially if it's about a feature a software simply does not have (yet?). ;)  
  > **username_2**: @username_0 if I may ask what is that in the images you try to protect? I had a use case where separate files (data and/or custom software artefacts) needed to be protected, so we used standard encryption/decryption (encrypt on build - decrypt on run). All the other parts are imho not worth to be protected. Not exact answer to your question but I find myself what is the business problem you need to solve.  
  > **username_0**: @PeterMuryshkin, nothing special, just the application (no secrets, no data). It's one of those customers who prefers not to have their stuff outside of their ("physical") intranet unencrypted. You know, large, ex-government...  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2018-05-25. Score: 2
  
  Google Container Registry is a potential option.
  
  1. Registry is private
  2. Image layers are stored on a Google Cloud Storage bucket, which is encrypted by Google (RSA) and can be additionally encrypted with a client key (RSA)
  3. Access control is granular down to each individual object stored on GCS bucket
  4. Client-side authentication is enforced via oauth2. Clients configure docker to use the google cloud sdk as a credentials manager
  5. Images are pulled via ssl connections
  
  The fact that the registry is part of Google's Cloud Platform also means you can build up to some other interesting things. For example, you could set up a VM to serve as reverse-proxy and set up the GCP firewall to only allow 443 from a certain set of IPs (like your clients' offices).
  
  
  ---
  
  ### Answer by username_4 on 2018-09-24. Score: 0
  
  Have a look at <https://github.com/Senetas/crypto-cli>
  
  It allows you to encrypt/decrypt containers when pushing and pulling from a public or private repo.
  
  (Full disclosure I know the guy who wrote it)
  
  
  ---
  
  