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

Re: Docker registry access in OSv3

For the OpenShift registry, we are planning the following:

- An automatic mapping from OpenShift ImageRepository to OpenShift Docker Registry repository, as you described below using project/namespace name and IR name.

- The OpenShift Docker Registry will use OpenShift for authentication and access control. If you have access to a particular IR in OpenShift, you’ll be able to push to/pull from the corresponding registry repo.

- The OpenShift Docker Registry will have some sort of quota enforcement. The card for that is currently here: https://trello.com/c/VT3Qb07g/294-5-registry-quotas-imageregistry-codefreeze. The details as to what quota applies to are still being ironed out. If you have suggestions, please add a comment to the card.

As far as allowing/disallowing certain registries to be used, I don’t believe we’ve had that discussion before.


On Feb 13, 2015, at 9:00 AM, Luke Meyer <lmeyer redhat com> wrote:

----- 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
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
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).

dev mailing list
dev lists openshift redhat com

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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