Origin: 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.

[simo5]

Mostly agree with having new role, even though it means, One. More. Role...

[jtudelag]

IMHO either option would be ok, create a new role system:image-creator or give system:image-pusher additional rights to create IS. As long as we clarify and correct the docs to avoid misunderstandings.

[smarterclayton]

I'm skeptical that adding a new role helps things. Let's construct
arguments why we'd consider expanding pusher a real security issue.

On Mon, Nov 20, 2017 at 4:18 PM, Jorge Tudela [e-mail]
wrote:

IMHO either option would be ok, create a new role system:image-creator or
give system:image-pusher additional rights to create IS. As long as we
clarify and correct the docs to avoid misunderstandings.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/issues/17341#issuecomment-345835031,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p4r0olKJUif2ocBQxmdeUDg-yThaks5s4eyvgaJpZM4QgPD0
.

[bparees]

I'm skeptical that adding a new role helps things. Let's construct
arguments why we'd consider expanding pusher a real security issue.

I don't think I do, I was just trying to satisfy your concerns raised on my PR:
"If someone wants the legacy behavior, how do they get it (you can only push to names I give you explicitly)?" (https://github.com/openshift/origin/pull/17363#issuecomment-345383561)

If "you can only push to names i give you explicitly" is no longer a use case, I'm happy to expand the existing role, per my original PR.

I don't see much difference between "i can push to a new imagestream in your project" and "i can push 50 million unique tags to any imagestream that already exists in your project"

If i trust you enough to overwrite tags i'm probably using, and consume my quota by pushing new tags, i trust you enough not to create new bad imagestreams.

[jtudelag]

I don't see much difference between "i can push to a new imagestream in your project" and "i can push 50 million unique tags to any imagestream that already exists in your project"

I partially disagree with this, I mean from a security perspective, in a scenario where there is no IS, this role is harmless.

So taking security in mind and also honouring the legacy behaviour, I would say creating a new role system:image-creator would be better.

Another option is closing this issue and file a doc bug to clarify the docs...but I still think a system:image-creator role makes sense and would fit in many use cases.

[bparees]

getting consensus on how to fix this proved unreasonably difficult, so i'm just doc'ing the limitation: https://github.com/openshift/openshift-docs/pull/6621