opendevstack/ods-project-quickstarters

cannot auto clone environment since OCP v3.6 without proper SA role assignment

gerardcl opened this issue · 12 comments

SA are not provided with self-provisioner role from OCP v3.6

Issue detected from: opendevstack/ods-jenkins-shared-library#109

TODO:
add in the automated process of project creation following solution: https://access.redhat.com/solutions/2988521

@gerardcl Please clarify first with rh what is needed.. seriously. ;-)

sure! already on a loop with them :) will keep you all posted

still pending a clear RH answer, but I can confirm that:

  • on a project I have applied that solution the auto cloning is working
  • on a project that this solution has yet not been applied the auto cloning is not working

I will test adding at project creation the following:

# https://access.redhat.com/solutions/2988521
oc adm policy add-cluster-role-to-user self-provisioner system:serviceaccount:${PROJECT}-cd:jenkins -n ${PROJECT}-cd

@gerardcl @michaelsauter Any news on this?
We have the very same problem. Only found the following sulution so far:

Add cluster-admin role to service account cd:deployment

oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:cd:deployment

This is requiered, so that deployment-sa can grant the self-provisioner role to the project-cd:jenkins user.

Add the self-provisioner role to service account project-cd jenkins

Script ocp-templates/scripts/create-projects.sh:

oc adm policy add-cluster-role-to-user self-provisioner system:serviceaccount:${PROJECT}-cd:jenkins --rolebinding-name=self-provisioner-${PROJECT}-jenkins

Problem
We don't like to give the deployment-service account such extensive rights by granting cluster-admin role.

this is the only way to do it - I guess :(

Let's test one more time that with the version in ODS one can 1. create a project via Jenkins and then 2. clone that newly created project. Then we can close this. @henrjk Can you help here?

Closing as test was successful without the cluster-wide roles.

@michaelsauter how were you able to do this without the cluster admin role for cd:deployment?
Have you done anything to your cluster?

Not that I am aware of. Why are you asking?

See comments above. Because as far as we know, there is no other option than what @stefanlack proposed. And that requires new rights.

@hugowschneider You do not set any new rights in your tests, correct? And the tests prove that creating new projects work as far as I know ...