{"action":"created","issue":{"url":"https://api.github.com/repos/opencontainers/image-spec/issues/747","repository_url":"https://api.github.com/repos/opencontainers/image-spec","labels_url":"https://api.github.com/repos/opencontainers/image-spec/issues/747/labels{/name}","comments_url":"https://api.github.com/repos/opencontainers/image-spec/issues/747/comments","events_url":"https://api.github.com/repos/opencontainers/image-spec/issues/747/events","html_url":"https://github.com/opencontainers/image-spec/issues/747","id":339537763,"node_id":"MDU6SXNzdWUzMzk1Mzc3NjM=","number":747,"title":"Proposal: New Mediatype - Container Image Encryption","user":{"login":"lumjjb","id":3060102,"node_id":"MDQ6VXNlcjMwNjAxMDI=","avatar_url":"https://avatars0.githubusercontent.com/u/3060102?v=4","gravatar_id":"","url":"https://api.github.com/users/lumjjb","html_url":"https://github.com/lumjjb","followers_url":"https://api.github.com/users/lumjjb/followers","following_url":"https://api.github.com/users/lumjjb/following{/other_user}","gists_url":"https://api.github.com/users/lumjjb/gists{/gist_id}","starred_url":"https://api.github.com/users/lumjjb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lumjjb/subscriptions","organizations_url":"https://api.github.com/users/lumjjb/orgs","repos_url":"https://api.github.com/users/lumjjb/repos","events_url":"https://api.github.com/users/lumjjb/events{/privacy}","received_events_url":"https://api.github.com/users/lumjjb/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":40,"created_at":"2018-07-09T17:20:12Z","updated_at":"2018-08-02T17:28:24Z","closed_at":null,"author_association":"NONE","body":"# Overview\r\n\r\nWe would like to propose a new media type for encrypted layers of a container image. This addition would facilitate the ecosystem for encrypted container images. This allows users with stricter trust requirements to be able ensure end-to-end encryption from build to runtime. In addition, it allows users to use a centralized managed repository (i.e. Docker Hub) without any risk of their images being compromised. \r\n\r\nProposal written and discussed by: \r\nBrandon Lum (@lumjjb), Dimitrios Pendarakis, Hani Jamjoom (@jamjoom), James Bottomley (@jejb), Phil Estes (@estesp), Stefan Berger (@stefanberger), Alaa Youssef within IBM.\r\n\r\nThis is a follow-up from a discussion with @stevvooe , and @dmcgowan at DockerCon.\r\n\r\n\r\n# Goals\r\nIn coming up with a proposal, we considered the following:\r\n- Application creators should not need to worry about details of encryption. Flows in the DevOps process and the runtime orchestration would be responsible for facilitating encryption.\r\n- Re-usability of layer de-duplication among container images\r\n- Encryption should be end-to-end, from the build step to when the container needs to be run on the worker machine. (i.e. registry owner should not be able to view the encrypted contents).\r\n- Encrypted images created can be for multiple trusted entities, and key management is responsible for managing that trust.\r\n- Specification should be easily integrated to generic with and across key management systems.\r\n- Secondary experimental goal: Allow more granular control of security, to provide possibility of desegregation and more fine-grained  security controls. (i.e. base OS, middleware, application can be encrypted separately).\r\n\r\n# Proposed Changes\r\nWe propose the following change:\r\n- Adding a mediaType: application/vnd.oci.image.layer.v1.tar+gzip+pgp to signify an encrypted layer (encrypted gzip).\r\n- For each layer with the above mediaType, add the following fields (either via annotations or within the spec):\r\n  - org.opencontainers.image.pgp.keys - An array of [wrapped symmetric keys](https://en.wikipedia.org/wiki/Key_Wrap), to be used to decrypt the layer (represented by comma-delimiter base64 separated strings). \r\n  - org.opencontainers.image.pgp.* - Other optional parameters that may be needed by encryption algorithms. I.e. choice of Hashes, Cipher function, etc.\r\n- Refer to \"Additional Details\" for further information on the encryption standards and data/key representation\r\n\r\nWith the changes, we expect an example of creating an encrypted image to look like the following:\r\n\r\n![image](https://user-images.githubusercontent.com/3060102/42897752-f63ed998-8a8e-11e8-834e-359be00a69c5.png)\r\n\r\n\r\nIn the creation of a container runtime bundle from the encrypted images, the runtime would perform an additional step of performing the decryption based on the information given in the annotations.\r\n\r\n# Additional Details\r\nWe include some of the interesting discussions we have about the proposal.\r\n\r\n## Encryption Standard\r\n\r\nThe encryption/decryption will be done will be according to OpenPGP standard as according to [RFC4800](https://tools.ietf.org/html/rfc4880). \r\n- The layer data will consists of Symmetrically Encrypted Data Packet as in [RFC4880 Section 5.7](https://tools.ietf.org/html/rfc4880#section-5.7)\r\n- The wrapped keys (org.opencontainers.image.pgp.keys) will be an array of Public-Key Encrypted Session Key Packets as in [RFC4880 Section 5.1](https://tools.ietf.org/html/rfc4880#section-5.1)\r\n- Decryption will be done by processing the wrapped key packets followed by the encrypted data packets. \r\n\r\n## Key Management\r\nThe purpose of Key Management is to assist in performing distribution, storage and use of keys. We note that this is important to be able to ensure that container runtimes are able to obtain the keys for decryption, and for encrypted container image creators to pass keys to their kubernetes/docker runtimes. However, we note that Key Management in itself can be seen as a separate component that assists the use of Encrypted Container Images. Therefore, we treat the process of Key Management as separate from the design of the Encrypted Container Images itself.\r\n\r\nWe note however, that Key Management is important in ensuring technology adoption. We discuss Key Management briefly. We have two models of key management that we consider, they are not exclusive and can probably be used in tandem. \r\n\r\n### Own Key Management\r\n\r\nKey management is handled by the operator of the cloud, and plugins are provided to allow interfacing with existing Key Management Solutions. In this case, the Key Management Solution (i.e. Vault, Azure Vault, IBM KeyProtect, etc.) need to be trusted by the company (run by themselves or by a trusted service).\r\n\r\n#### An example:\r\nCompany A has an existing internal Vault service. To build an image, the build machine or developer generates a symmetric key through Vault to perform encryption of the image. This symmetric key is then stored in the Vault service via an Encrypted Container Image Vault plugin. To run the image, the administrator configures it's kubernetes cluster with a Vault token to use the internal vault service via a Encrypted Container Image Vault plugin. \r\n\r\n### Fully Centralized Untrusted Key Distribution (FCUKD)\r\n\r\nKey management is handled by users and container runtimes interacting with an untrusted Key Distribution server (alongside container image registry). Private keys are still managed individually by users but no additional external party's trust is required (if server is compromised, no keys are lost). In addition, it provides a central location for users to manage. The trust model is similar to that of Docker Notary server.\r\n\r\n#### An example:\r\nTo build an image, the build machine or developer generates a symmetric key and performs the encryption of the image. The symmetric key is then wrapped with the public key of the entities/receipients that it allows access to and registered with the FCUKD server. \r\n\r\nWe spin up a new cluster (that operates uses a docker ID of orgcluster). The kubernetes cluster runtime downloads an encrypted image and identifies it does not have the necessary keys to decrypt the image. The runtime sends a request for the key for the layer to the FCUKD server. The approver (image owner or delegate) gets a notification of the request, and verifies, approves and submits a wrapped key to the system. Thereafter,  the requestor (cluster) can download unwrap and use the symmetric key to decrypt the container image. The approval process may be automated through an Access Control Lists set by the key owner.\r\n\r\nWe note that it is possible to provide the symmetric key to the Fully Centralized Untrusted Key Distribution system and perform auto-approvals, but it is highly discouraged since it weakens the security of the system. "},"comment":{"url":"https://api.github.com/repos/opencontainers/image-spec/issues/comments/410005776","html_url":"https://github.com/opencontainers/image-spec/issues/747#issuecomment-410005776","issue_url":"https://api.github.com/repos/opencontainers/image-spec/issues/747","id":410005776,"node_id":"MDEyOklzc3VlQ29tbWVudDQxMDAwNTc3Ng==","user":{"login":"stefanberger","id":1873348,"node_id":"MDQ6VXNlcjE4NzMzNDg=","avatar_url":"https://avatars3.githubusercontent.com/u/1873348?v=4","gravatar_id":"","url":"https://api.github.com/users/stefanberger","html_url":"https://github.com/stefanberger","followers_url":"https://api.github.com/users/stefanberger/followers","following_url":"https://api.github.com/users/stefanberger/following{/other_user}","gists_url":"https://api.github.com/users/stefanberger/gists{/gist_id}","starred_url":"https://api.github.com/users/stefanberger/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stefanberger/subscriptions","organizations_url":"https://api.github.com/users/stefanberger/orgs","repos_url":"https://api.github.com/users/stefanberger/repos","events_url":"https://api.github.com/users/stefanberger/events{/privacy}","received_events_url":"https://api.github.com/users/stefanberger/received_events","type":"User","site_admin":false},"created_at":"2018-08-02T17:28:24Z","updated_at":"2018-08-02T17:28:24Z","author_association":"NONE","body":"@wking Can one currently push any images where the JSON documents were (re-)written by containerd? My guess is that our failed attempts to push images should actually be quite common."}}
{"actor":{"display_login":"stefanberger"}}