[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Docker registry access in OSv3

----- Original Message -----
> From: "Erik M Jacobs" <ejacobs redhat com>
> To: "Luke Meyer" <lmeyer redhat com>, "Openshift Dev" <dev lists openshift redhat com>
> Sent: Friday, February 13, 2015 8:41:04 AM
> Subject: Re: Docker registry access in OSv3
> On 02/13/2015 01:05 AM, Luke Meyer wrote:
> > With the sample app
> > (https://github.com/openshift/origin/tree/master/examples/sample-app)
> > and in other places, we're discussing having STI builders push an
> > image to a Docker registry (running on OpenShift or outside it)
> > and having that kick off a deployment of that image.
> > 
> > Here are the questions that arise:
> > 1. How do we put quotas on how much registry space a project can
> > use?
> > 2. How do we prevent projects from pushing images that stomp on
> > same-named images pushed by other projects?
> > 
> > If the ability to push images is always mediated by
> > ImageRepositories, and we automatically add the project namespace
> > to the image name (so, a project "foo" with IR "bar" always pushes
> > images named "foo/bar" to the docker-registry service), that takes
> > care of 2. Not sure if that's the intended design?
> Well, it depends on the naming schema. Remember that in OpenShift 2,
> hyphens are not allowed in user namespaces. If you allow hyphens, and
> your concatenation scheme includes hyphens, you run into this issue:
> Joe's namespace: joe-foo
> Joe's image: food
> Result: food-joe-foo
> Sue's namespace: foo
> Sue's image: food-joe
> Result: food-joe-foo
> Which is a collision
> So, #2 is potentially solved as long as we pay attention to naming
> schema, and, ironically, we are in the process of trying to get docker
> registry to accept more characters.

Yes, but the concatenation scheme is with "/" :)

On DockerHub, the bit before the / is your username, and the part after is the image name. I don't know if this sort of scoping has any particular meaning to a non-DockerHub registry or just becomes convention there.

I meant to say something also about security here. If we simply establish a convention that's generally followed for registry usage, it will prevent accidental stompage. But if we don't have some way to *enforce* access control, it would not be hard for someone malicious to push an image to someone else's "registry space" that is picked up and deployed in place of what they wanted. And while we like to believe our PaaS users are all too nice to do that, a lot of platform administrators won't be able to assume that.

> > The question of quotas seems harder. Resource limits can be defined
> > in OpenShift but some kind of registry plugin would be required
> > for the docker-registry to enforce them, if it has the ability at
> > all. And is there a mechanism for administratively pointing at
> > some external registry? Maybe just point the docker-registry
> > service at an external IP?
> And the other question - how do we restrict what images may be pulled IN
> and from where. Should a user be allowed to just pull in "mysql" from
> DockerHub? What if the people using OpenShift have a corporate registry
> for their ISV software (eg: SAP) but then have a different registry for
> something else, and they want to make both available?


> > One other possibility would be requiring each project that does
> > image builds to host its own docker registry. It would handle the
> > quota issue nicely, but would probably seem cumbersome to users.
> Well, how would it handle the quota issue? If the registry itself
> doesn't enforce them, how would OpenShift enforce it? What process
> exists or would be able to be created that would prevent someone from
> pushing to their project's registry? And, if we created such a process,
> why wouldn't it also apply to a central registry?

It would "handle the quota issue" because the registry would be running in a pod that counted against the project's quota (being further limited by whatever disk size constraint they put on the pod). So if they shoved too much stuff in there it would run out of space, and that would be their problem to solve. Not super friendly, I am not a fan, but effective. Probably also assists with the security issue mentioned above (if you don't have the project-scoped secrets to access its registry, you can't do anything with it).

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]