Have we considered provisioning SSL certs and keys as a separate step (isolation maybe)? This could mean mounting “.ssl” volume inside the container for example.
-Jojy > On Mar 15, 2016, at 11:18 AM, Avinash Sridharan <avin...@mesosphere.io> wrote: > > Why not follow option 2, but instead of passing the agent credentials, pass a > location to the flag where credentials for the registry can be found (in > JSON)? The frameworks can set credentials (maybe registry name or URL to the > registry), and the credentials can be learnt from the JSON config. > > With option 1, won't we need to mutate the frameworks to make them more > secure ? > > On Tue, Mar 15, 2016 at 10:48 AM, Gilbert Song <gilb...@mesosphere.io > <mailto:gilb...@mesosphere.io>> wrote: > Hi folks, > > We want to raise a discussion here, seeking suggestions about passing > credentials in a secure way. This relates to the JIRA MESOS-4938 > <https://issues.apache.org/jira/browse/MESOS-4938>, supporting docker private > registry authentication in unified containerizer. In fact, this problem is > not limited to docker registry. For instance, how can we support > CommandInfo.URIs that need credentials? > > For the docker registry problem, credentials have to be included when > communicating with the docker auth server. We have two options here: > > Option 1: Passing credentials in protobuf Image::Docker. > Pros: This means supporting per-container docker registry, which is robust > because different registry can be reached by an agent, configurable by users. > Cons: So SSL has to be enabled to encrypt the communication between master > and slave to prevent credentials from being seen by others. We also need to > make sure we don’t expose credentials in any endpoint. > > Option 2: Passing credentials as an agent flag. > Pros: Not necessary to be SSL enabled. > Cons: No per-container registry support (imagine a multi-tenant cluster). > > Some background: How does docker containerizer solve this issue? > In docker containerizer, we ask the framework to specify a URI for their > task/executor that points to the .dockercfg(now ~/.docker/config.json) which > contains the user and password information. The .dockercfg will be saved in > the sandbox by the fetcher. When we call docker pull, we set the $HOME env > for the subprocess to point to the sandbox so that the docker client can pick > up that .dockercfg when pulling images. > > Any comment/advice will be absolutely welcome! > > Thanks, > Gilbert/Jie > > > > -- > Avinash Sridharan, Mesosphere > +1 (323) 702 5245
