Description of problem: Customer has 2 clusters configured the same. On both clusters, "oadm policy who-can create project" shows the service account as one of the allowed objects. On one cluster, the service account can create projects, on the other it can't. Version-Release number of selected component (if applicable): atomic-openshift-3.5.5.31-1.git.0.b6f55a2.el7.x86_64 How reproducible: Always, on this cluster with this SA Steps to Reproduce: 1. Create a service account 2. Enable the service account to create projects 3. Create a project Actual results: "stderr": "Error from server (Forbidden): You may not request a new project via this API.","stderr_lines": ["Error from server (Forbidden): You may not request a new project via this API. Expected results: project created Additional info:
can you provide server logs for both the working and non working commands at the time they are executed ?
Sten please report on: oadm policy who-can create projectrequests oadm policy who-can list projectrequests for b oth clusters
@Sten As you can see from the output of `who-can create project`, a very small set of users can perform such actions. The reason is that the direct creation of projects (and namespaces) is a highly privileged and controlled action. Thus to allow a normal user to safely interact with the API, we provide the extra indirection of a `projectrequest` (this is what `oc new-project` invokes). This is a way of stating to the API that you want a project created on your behalf. It allows the API to fully control how the project will be created via the cluster's project template, while giving the appearance to the user that they created the project. With this in mind, I strongly suggest that you remove the ability to directly create projects from both service accounts, and instead give them create/list on projectrequests. If for some reason you need to directly allow the creation of projects from these SAs (and skip the project template), use the `oc adm new-project` command.
Created attachment 1328449 [details] projectrequests perms
It seem it was a custom configuration issue after all, closing as not a bug