Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

template cannot fill in "current" namespace for binding cluster resources to namespace-scoped #8971

Closed
sosiouxme opened this issue May 20, 2016 · 3 comments

Comments

@sosiouxme
Copy link
Member

sosiouxme commented May 20, 2016

The desire is to create service accounts in a namespace (not known a priori) with the roles already bound, to prevent having to instruct users in how to add them afterward.

This works fine for a RoleBinding as it is already a namespace-scoped object and the client creates it within the scope of a project and the subject of the binding can be inferred. It doesn't work for adding a ClusterRoleBinding as that has no namespace scope; the namespace has to be specified in the definition, which leaves the template in the awkward position of filling in the intended namespace via a parameter.

Version

$ oc version
oc v1.3.0-alpha.0-619-g2dde6d7-dirty
kubernetes v1.3.0-alpha.1-331-g0522e63

Steps To Reproduce

Attempt to create from the following template:

  apiVersion: "v1"
  kind: "Template"
  metadata:
    name: apiman-deployer-account-template
    annotations:
      description: "Template for creating the service accounts needed for the APIMan deployer."
      tags: "infrastructure"
    labels:
      apiman-infra: support
  objects:
  -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: apiman-deployer
    secrets:
    - name: apiman-deployer
  -
    apiVersion: v1
    kind: RoleBinding
    metadata:
      name: deployer-edit-role
    roleRef:
      kind: ClusterRole
      name: system:router
    subjects:
    - kind: ServiceAccount
      name: apiman-deployer
  -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: apiman-elasticsearch
  -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: apiman-curator
  -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: apiman-gateway
  -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: apiman-console
  -
    apiVersion: v1
    kind: ClusterRoleBinding
    metadata:
      name: apiman-cluster-reader-role
    roleRef:
      kind: ClusterRole
      name: cluster-reader
    subjects:
    - kind: ServiceAccount
      name: apiman-gateway
    - kind: ServiceAccount
      name: apiman-console
Current Result

The RoleBinding is created but there is an error on the ClusterRoleBinding.

$ oc new-app apiman-deployer-account-template
--> Deploying template apiman-deployer-account-template for "apiman-deployer-account-template"
--> Creating resources ...
    serviceaccount "apiman-deployer" created
    rolebinding "deployer-edit-role" created
    serviceaccount "apiman-elasticsearch" created
    serviceaccount "apiman-curator" created
    serviceaccount "apiman-gateway" created
    serviceaccount "apiman-console" created
    error: RoleBinding "apiman-cluster-reader-role" is invalid: [subjects[0].namespace: Required value, subjects[1].namespace: Required value]
--> Failed
Expected Result

There is a way for the "current" project to be filled in on the service account subject, other than having to specify it explicitly with a template parameter PROJECT=foo or similar.

@deads2k
Copy link
Contributor

deads2k commented May 23, 2016

question for @bparees that I think he's answered a few times.

@deads2k deads2k assigned bparees and unassigned deads2k May 23, 2016
@bparees
Copy link
Contributor

bparees commented May 23, 2016

Right, there's no way to do this today, template parameters don't have any way to pick up values from the system, they can only do generic substitution. And there's no way to leverage the downward api except when defining env variables. I think we have at least one other issue open requesting this capability, but since i don't want to try to track it down, i'll leave this one open too :)

@bparees
Copy link
Contributor

bparees commented Oct 14, 2016

trello https://trello.com/c/zcRQFri0

@bparees bparees closed this as completed Oct 14, 2016
domq pushed a commit to epfl-si/wp-ops that referenced this issue Feb 25, 2019
* Generate qdirstat report every night using a modified version of the
  script referenced by https://superuser.com/a/1028907/48763 (freeware
  / public domain)

* Run the script in a slightly modified version of the "perl" stock
  Docker image

* Plumb down all the Kubernetes / OpenShift objects to build the
  image, host the script (from a ConfigMap), and run it (as a k8s
  CronJob)

* Jury-rigged Makefile to work around
  openshift/origin#8971 and share the YAML
  between test and production
domq pushed a commit to epfl-si/wp-ops that referenced this issue Feb 28, 2019
* Generate qdirstat report every night using a modified version of the
  script referenced by https://superuser.com/a/1028907/48763 (freeware
  / public domain)

* Run the script in a slightly modified version of the "perl" stock
  Docker image

* Plumb down all the Kubernetes / OpenShift objects to build the
  image, host the script (from a ConfigMap), and run it (as a k8s
  CronJob)

* Jury-rigged Makefile to work around
  openshift/origin#8971 and share the YAML
  between test and production
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants