{"action":"created","issue":{"url":"https://api.github.com/repos/docker/docker/issues/13490","labels_url":"https://api.github.com/repos/docker/docker/issues/13490/labels{/name}","comments_url":"https://api.github.com/repos/docker/docker/issues/13490/comments","events_url":"https://api.github.com/repos/docker/docker/issues/13490/events","html_url":"https://github.com/docker/docker/issues/13490","id":81134963,"number":13490,"title":"Secrets: write-up best practices, do's and don'ts, roadmap","user":{"login":"thaJeztah","id":1804568,"avatar_url":"https://avatars.githubusercontent.com/u/1804568?v=3","gravatar_id":"","url":"https://api.github.com/users/thaJeztah","html_url":"https://github.com/thaJeztah","followers_url":"https://api.github.com/users/thaJeztah/followers","following_url":"https://api.github.com/users/thaJeztah/following{/other_user}","gists_url":"https://api.github.com/users/thaJeztah/gists{/gist_id}","starred_url":"https://api.github.com/users/thaJeztah/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thaJeztah/subscriptions","organizations_url":"https://api.github.com/users/thaJeztah/orgs","repos_url":"https://api.github.com/users/thaJeztah/repos","events_url":"https://api.github.com/users/thaJeztah/events{/privacy}","received_events_url":"https://api.github.com/users/thaJeztah/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/docker/docker/labels/kind/security","name":"kind/security","color":"CF6F90"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-05-26T21:01:43Z","updated_at":"2015-06-07T17:29:00Z","closed_at":null,"body":"Handling secrets (passwords, keys and related) in Docker is a recurring topic. Many pull-requests have been 'hijacked' by people wanting to (mis)use a specific feature for handling secrets.\r\n\r\nSo far, we only *discourage* people to use those features, because they're either provenly insecure, or not designed for handling secrets, hence \"possibly\" insecure. We *don't* offer them real alternatives, at least, not for all situations and *if*, then without a practical example.\r\n\r\nI just think \"secrets\" is something that has been left lingering for too long. This results in users (mis)using features that are not designed for this (with the side effect that discussions get polluted with feature requests in this area) and making them jump through hoops just to be able to work with secrets.\r\n\r\n\r\n### Features / hacks that are (mis)used for secrets\r\n\r\nThis list is probably incomplete, but worth a mention\r\n\r\n- **Environment Variables**. Probably the most used, because it's part of the [\"12 factor app\"](http://12factor.net). Environment variables are discouraged, because they are;\r\n    - Accessible by any proces in the container, thus easily \"leaked\"\r\n    - Preserved in intermediate layers of an image, and visible in docker inspect\r\n    - Shared with any container linked to the container\r\n- **Build-time environment variables** (https://github.com/docker/docker/pull/9176). The build-time environment variables were **not** designed to handle secrets. By lack of other options, people are planning to use them for this. To prevent giving the *impression* that they are suitable for secrets, it's been decided to deliberately **not** encrypt those variables in the process.\r\n- **Mark .. Squash / Flatten layers**. (https://github.com/docker/docker/issues/332, https://github.com/docker/docker/pull/12198, https://github.com/docker/docker/pull/4232, https://github.com/docker/docker/pull/9591). Squashing layers will remove the intermediate layers from the final image, however, secrets used in those intermediate layers will still end up in the build cache.\r\n- **Volumes**. IIRC some people were able to use the fact that volumes are re-created for each build-step, allowing them to store secrets. I'm not sure this actually works, and can't find the reference to how that's done.\r\n- **Manually building containers**. Skip using a Dockerfile and manually build a container, commiting the results to an image\r\n- **Custom Hacks**. For example, hosting secrets on a server, `curl`-ing the secrets and remove them afterwards, all in a single layer.\r\n\r\n\r\n### So, what's needed?\r\n\r\n- Add documentation on \"do's\" and \"don'ts\" when dealing with secrets; @diogomonica made some excellent points in https://github.com/docker/docker/pull/9176#issuecomment-99542089\r\n- Describe the officially \"endorsed\" / approved way to handle secrets, if possible, using the *current* features\r\n- Provide roadmap / design for officially handling secrets, we may want to make this pluggable, so that we don't have to re-invent the wheel and use existing offerings in this area, for example, [Vault](https://www.vaultproject.io), [Keywiz](http://square.github.io/keywhiz/), [Sneaker](https://github.com/codahale/sneaker)\r\n\r\nThe above should be written / designed with both **build-time** and **run-time** secrets in mind\r\n\r\n@calavera created a quick-and-dirty proof-of-concept on how the new Volume-Drivers (https://github.com/docker/docker/pull/13161) could be used for this; https://github.com/calavera/docker-volume-keywhiz-fs\r\n\r\n\r\n> **Note:** Environment variables are used as the de-facto standard to pass configuration/settings, **including secrets** to containers. This includes official images on Docker Hub (e.g. [MySQL](https://registry.hub.docker.com/_/mysql/), [WordPress](https://registry.hub.docker.com/_/wordpress/), [PostgreSQL](https://registry.hub.docker.com/_/postgres/)). These images should adopt the new 'best practices' when written/implemented.\r\n\r\n\r\n\r\nIn good tradition, here are some older proposals for handling secrets;\r\n\r\n- \"Add private files support\" https://github.com/docker/docker/pull/5836\r\n- \"Add secret store\" https://github.com/docker/docker/pull/6075\r\n- \"Continuation of the `docker secret` storage feature\" https://github.com/docker/docker/pull/6697\r\n- \"Proposal: The Docker Vault\" https://github.com/docker/docker/issues/10310\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/docker/docker/issues/comments/109778725","html_url":"https://github.com/docker/docker/issues/13490#issuecomment-109778725","issue_url":"https://api.github.com/repos/docker/docker/issues/13490","id":109778725,"user":{"login":"thaJeztah","id":1804568,"avatar_url":"https://avatars.githubusercontent.com/u/1804568?v=3","gravatar_id":"","url":"https://api.github.com/users/thaJeztah","html_url":"https://github.com/thaJeztah","followers_url":"https://api.github.com/users/thaJeztah/followers","following_url":"https://api.github.com/users/thaJeztah/following{/other_user}","gists_url":"https://api.github.com/users/thaJeztah/gists{/gist_id}","starred_url":"https://api.github.com/users/thaJeztah/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thaJeztah/subscriptions","organizations_url":"https://api.github.com/users/thaJeztah/orgs","repos_url":"https://api.github.com/users/thaJeztah/repos","events_url":"https://api.github.com/users/thaJeztah/events{/privacy}","received_events_url":"https://api.github.com/users/thaJeztah/received_events","type":"User","site_admin":false},"created_at":"2015-06-07T17:29:00Z","updated_at":"2015-06-07T17:29:00Z","body":"@diogomonica although not *directly* related, there a long open feature request for forwarding SSH key agent during build; https://github.com/docker/docker/issues/6396 given the number of comments, it would be good to give that some thinking too. (If even to take a decision on it whether or not it can/should be implemented)"}}