Origin: whats the canonical YAML way to add a Role and a RoleBinding for a ServiceAccount into a Template?

[jstrachan]

I've seen how to add roles via the CLI, but how should we define the required Role and RoleBinding for a ServiceAccount inside an OpenShift Template?

I could create a role OK:

---
apiVersion: "v1"
kind: "Role"
metadata:
  labels:
    provider: "fabric8"
    project: "jenkins-openshift"
  name: "jenkins"
rules:
- resources:
  - "pod"
  verbs:
  - "create"
  - "delete"
  - "deletecollection"
  - "get"
  - "list"
  - "watch"

then struggled to refer to the role in the RoleBinding

---
apiVersion: "v1"
kind: "RoleBinding"
metadata:
  labels:
    provider: "fabric8"
    project: "jenkins-openshift"
  name: "jenkins"
roleRef:
  name: "jenkins"
subjects:
- kind: "ServiceAccount"
  name: "jenkins"

Is there a way to refer to a role in the current namespace? I've seen system:admin to refer to global roles but haven't seen the magic prefix to refer to a local role inside a namespace.

Any ideas?

[liggitt]

specify a namespace in the roleRef to refer to a locally defined role. note that a policybinding for for the local namespace must exist before you can bind to locally defined roles. You can create that with oc create policybinding <myns>

[jstrachan]

thanks @liggitt

So I need to do something like this...

---
apiVersion: "v1"
kind: "RoleBinding"
metadata:
  labels:
    provider: "fabric8"
    project: "jenkins-openshift"
  name: "jenkins"
roleRef:
  name: "${NAMESPACE}:jenkins"

then define the NAMESPACE expression in a Template parameter or something? I was hoping there was a notation to refer to a namespace local role - I guess not?

[liggitt]

No,

roleRef:
  name: myrole
  namespace: myns

[liggitt]

Ah, the issue with not knowing the destination namespace when processing a template.

[jstrachan]

@liggitt yeah ;) I was hoping we could get a template parameter defined for the namespace the template is being created inside; like the downward API on env vars can be used to define an env var for a namespace - but I don't see how.

If the namespace is missed off the roleRef I would have thought it'd assume the current namespace though? If it was a global or system role I thought you'd have to specify that explicitly using some magic name like "system" or something?

e.g. when you create a kubernetes resource there's metadata.namespace and you leave it blank if you want the current namespace & things just work - then kubernetes will fill in empty namespaces with the current one. It feels like the RoleBinding and PolicyBinding should work the same really

[bparees]

you can now set the namespace field in terms of a parameter value. There is still no automatic/implicit parameter that tells you the current namespace though, you have to collect that value from the user as a parameter.

Might be good enough to close this, though.

[jim-minter]

@liggitt @smarterclayton there was not unreasonable reluctance recently (#16021) to add the capability for templates to have a defaulting NAMESPACE parameter, and I think this is the number one use case. To get the current namespace into pod environment variables, downward API (env/valueFrom/fieldRef/fieldPath/metadata.namespace) can be used. Would it be possible to add an equivalent to the RoleBinding roleRef field? It would probably mean we could do away with having NAMESPACE as a parameter in quite a lot of templates.

[jim-minter]

@jorgemoralespou fyi

[liggitt]

If you target 3.7+, you can use kubernetes RBAC objects for roles/bindings, and when specifying a roleRef, you must specify kind of ClusterRole or Role, and a ref to a Role is automatically to the rolebinding's namespace

[smarterclayton]

This already works on 3.4+ - use the ref with no namespace and kind service
account.

On Sep 12, 2017, at 6:30 PM, Jordan Liggitt [e-mail]
wrote:

If you target 3.7+, you can use native RBAC objects for roles/bindings, and
when specifying a roleRef, you must specify kind of ClusterRole or Role,
and a ref to a Role is automatically to the rolebinding's namespace

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

[bparees]

sounds closeable.

[jim-minter]

This already works on 3.4+ - use the ref with no namespace and kind service
account.

@smarterclayton I'm not following - doesn't that just avoid the need to specify the namespace of the SA? I'm talking about the namespace of the Role. Every time I don't specify it, OpenShift interprets it as meaning a ClusterRole.

[liggitt]

Every time I don't specify it, OpenShift interprets it as meaning a ClusterRole.

Right. The kube RBAC types specify kind: Role in the roleRef

[anderssv]

A bit unclear to me. Anyone verified this pre 3.7? We're on 3.6 and the following does not work without specifying the namespace:

apiVersion: v1
kind: RoleBinding
metadata:
  name: openshift-cluster-basetest
roleRef:
  kind: Role
  name: openshift-cluster-basetest
  namespace: cluster-test
subjects:
- kind: ServiceAccount
  name: openshift-cluster-basetest

[parberge]

@anderssv On 3.7 I still need to specify namespace when doing the RoleBinding

[Asgoret]

Hi @jstrachan, can you help with my case?)
Whell....i catch erorr after you fix this errot) Now, you didnt specifynamespaceinsubject, BUT if you dont write namespace RoleBinding end without error, but past user without namespace. See file.

Full code:

kind: ServiceAccount
apiVersion: v1
metadata:
  name: test
secrets:
- fieldPath: metadata.namespace

kind: RoleBinding
apiVersion: v1
metadata:
 name: test
roleRef:
 apiGroup: v1
 kind: Role
 name: admin
subjects:
- apiVersion: v1
  fieldPath: metadata.namespace
  kind: ServiceAccount
  name: test

And if i add namespace: test to subjects: