Role system:image-pusher does not allow to push images.

[jtudelag]

The clusterrole system:image-pusher does NOT allow to push images.

Version

oc version
oc v3.6.173.0.49
kubernetes v1.6.1+5115d708d7
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://lb.karmalabs.local:8443
openshift v3.6.173.0.49
kubernetes v1.6.1+5115d708d7

In OCP 3.5 does not work neither.

Steps To Reproduce

1. Give a user the role system:image-pusher
   oc adm policy add-cluster-role-to-user system:image-pusher "USER"

2. Log into oc with that user
   oc login "USER"..

3. Get user token
   token=$(oc whoami -t)

4. Log into the registry with Docker cli
   docker login -u "USER" -p $token

5. Try to push an image
   docker push...

Current Result

"denied: requested access to the resource is denied"

docker push myregistry.example.com/test-push/test-push:latest
The push refers to a repository [myregistry.example.com/test-push/test-push]
a11fda45870e: Mounted from test-push/test-push
denied: requested access to the resource is denied

Expected Result

The docker push command to ends with no errors ;)

[jtudelag]

The role is defined like this:

`apiVersion: v1
kind: ClusterRole
metadata:
annotations:
openshift.io/description: Grants the right to push and pull images from within
a project.
creationTimestamp: null
name: system:image-pusher
rules:

• apiGroups:
  • image.openshift.io
  • ""
    attributeRestrictions: null
    resources:
  • imagestreams/layers
    verbs:
  • get
  • update`

But I think It should also allow to create imagestreams:

`apiVersion: v1
kind: ClusterRole
metadata:
annotations:
openshift.io/description: Grants the right to push and pull images from within
a project.
creationTimestamp: null
name: system:image-pusher
rules:

• apiGroups:
  • image.openshift.io
  • ""
    attributeRestrictions: null
    resources:
  • imagestreams/layers
    verbs:
  • get
  • update
• apiGroups:
  • image.openshift.io
  • ""
    attributeRestrictions: null
    resources:
  • imagestreams
    verbs:
  • create`

[bparees]

near as I can tell, this is a bug and we should be adding the "create" permission(along with retaining get+update) to the image-pusher. @deads2k are you aware of a reason this was done this way?

[deads2k]

near as I can tell, this is a bug and we should be adding the "create" permission(along with retaining get+update) to the image-pusher. @deads2k are you aware of a reason this was done this way?

I don't remember off-hand. I do remember @smarterclayton asking me to twiddle it for a build role somewhere a while back.

[simo5]

@bparees I thought this was intentional as privileged users would provide known good base images and people would just always use them and only push layers on top.
If that is not the case and image-pusher should be able to create brand new images from scratch than yeah we should probably add the create imagestreams permission.
But before we do that I would like to have a definitive answer on what is the intention behind the image-pusher role, who created it ? Can we get the "truth" from the source ?

[bparees]

But before we do that I would like to have a definitive answer on what is the intention behind the image-pusher role, who created it ? Can we get the "truth" from the source ?

that's what i'm trying to do....

[jtudelag]

In any case, I think also that the OCP docs should be clarified:
https://docs.openshift.com/container-platform/3.6/dev_guide/managing_images.html#creating-an-image-stream-by-manually-pushing-an-image

If the behaviour is intentional, docs should state that the imagestream have to exist before pushing it...

[smarterclayton]

I created image-pusher.

The intent was that a normal openshift user could both tag images and also push to them. We added the "create image stream" as a convenience so that you didn't have to have an image stream created to push to, just like any normal docker registry.

There are two roles at play:

• "edit" (i am a user logged in to a namespace). Editors can create image streams and this is not a problem
• "system:image-pusher" automated processes pushing images on a user's behalf. This is the one that we could potentially break.

Current things that have pusher:

• service accounts like the builder
• users granted because it's the easiest role to give that restricts permissions below edit (hey, i want you to be able to push this image, oh here's the right role)
• other machine systems like jenkins that might need it to do its job

I'm only concerned about the security implications of broadening for the middle one. Do we think anyone using OpenShift is relying on the fact that image-pushers can't create image streams in order to limit the amount of things they can tag? Since image-pusher can overwrite any tag, or tag an endless amount of images, or create unlimited tags inside an existing stream, it doesn't seem like not giving them image stream create saves us anything.

I'm inclined to give system:image-pusher create on image streams and document that why we did it in a release note.

[bparees]

I'm only concerned about the security implications of broadening for the middle one.

personally i'd be ok with just introducing another role ("image-creator"?) that can both create new imagestreams, and push to existing ones(update).

(and then updating the doc to explain the difference).

That way we don't break anyone's existing flow, but going forward people have a role that does what they seem to expect.

Note that builder SAs today have both image-pusher and a separate "create imagestreams" permission. They could just be granted image-creator instead if we did this.