doc: improve documentation for create-ocp-project #924
Conversation
| To obtain an OpenShift API token, create a Service Account, assign permissions to it, and request a token: | ||
|
|
||
| ```bash | ||
| oc create sa orchestrator-ocp-api |
There was a problem hiding this comment.
@gabriel-farache can you confirm the SA permissions? I tried admin and self-provisioner roles, but those failed. I had to use cluster-admin to get the project creation to work.
There was a problem hiding this comment.
It's interesting that admin cluster role failed, when checking why:
$ oc adm policy add-cluster-role-to-user admin -z orchestrator-ocp-api3
clusterrole.rbac.authorization.k8s.io/admin added: "orchestrator-ocp-api3"
$ oc auth can-i get project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api3
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
yes
$oc auth can-i create project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api3
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
no
In the workflow we are creating then reading the project created to get its state.
To create the project we are sending a POST request to /apis/project.openshift.io/v1/projects, and we can see that the admin cannot create a project
But
$ oc auth can-i create projectrequest --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api3
Warning: resource 'projectrequests' is not namespace scoped in group 'project.openshift.io'
yes
It appears that what we are doing is wrong, instead, we should send a POST request to /apis/project.openshift.io/v1/projectRequests for which the admin and self-provisioner cluster roles are set to allow its creation.
I will update the workflow to stick to the OCP way of creating project.
FYI self-provisioner only is not enough:
$ oc adm policy add-cluster-role-to-user self-provisioner -z orchestrator-ocp-api4
clusterrole.rbac.authorization.k8s.io/self-provisioner added: "orchestrator-ocp-api4"
$ oc auth can-i create projectrequest --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api4
Warning: resource 'projectrequests' is not namespace scoped in group 'project.openshift.io'
yes
$ oc auth can-i get project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api4
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
no
We need the admin:
$ oc adm policy add-cluster-role-to-user admin -z orchestrator-ocp-api4
clusterrole.rbac.authorization.k8s.io/admin added: "orchestrator-ocp-api4"
$ oc auth can-i get project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api4
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
yes
Using the cluster-admin will work but it will be able to do anything on the cluster, whereas the admin may have more restricted set of permissions
Alternatively, we could add a step to create a cluster role to get the project
$oc create clusterrole read-project --verb=get --resource=projects
clusterrole.rbac.authorization.k8s.io/read-project created
$ oc adm policy add-cluster-role-to-user read-project -z orchestrator-ocp-api4
clusterrole.rbac.authorization.k8s.io/read-project added: "orchestrator-ocp-api4"
$ oc auth can-i get project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api4
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
yes
There was a problem hiding this comment.
The PR parodos-dev/serverless-workflows#490 to stick to OCP behaviour when creating OCP project
There was a problem hiding this comment.
Alternatively, we could add a step to create a cluster role to get the project
You mean a cluster role that can create/list projects?
There was a problem hiding this comment.
Alternatively, we could add a step to create a cluster role to get the project
You mean a cluster role that can create/list projects?
No, just get a project: in the workflow, once the project is created, we retrieve the project to get its status.
We do not need to list all of the projects as we are not checking if a project with similar name exists.
And we do not need create either as parodos-dev/serverless-workflows#490 introduced a change to use ProjectRequest kind when creating a project instead of using a POST on the Project API.
If we want to use this alternative ( creating a cluster role), the SA will have to get assigned to self-provisioner (which provides the permissions to create a ProjectRequest) and the newly create cluster role (which would provides the get permission on Project)
evanshortiss
changed the title
|
@evanshortiss thank you for your contribution |
| To obtain an OpenShift API token, create a Service Account, assign permissions to it, and request a token: | ||
|
|
||
| ```bash | ||
| oc create sa orchestrator-ocp-api |
There was a problem hiding this comment.
It's interesting that admin cluster role failed, when checking why:
$ oc adm policy add-cluster-role-to-user admin -z orchestrator-ocp-api3
clusterrole.rbac.authorization.k8s.io/admin added: "orchestrator-ocp-api3"
$ oc auth can-i get project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api3
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
yes
$oc auth can-i create project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api3
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
no
In the workflow we are creating then reading the project created to get its state.
To create the project we are sending a POST request to /apis/project.openshift.io/v1/projects, and we can see that the admin cannot create a project
But
$ oc auth can-i create projectrequest --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api3
Warning: resource 'projectrequests' is not namespace scoped in group 'project.openshift.io'
yes
It appears that what we are doing is wrong, instead, we should send a POST request to /apis/project.openshift.io/v1/projectRequests for which the admin and self-provisioner cluster roles are set to allow its creation.
I will update the workflow to stick to the OCP way of creating project.
FYI self-provisioner only is not enough:
$ oc adm policy add-cluster-role-to-user self-provisioner -z orchestrator-ocp-api4
clusterrole.rbac.authorization.k8s.io/self-provisioner added: "orchestrator-ocp-api4"
$ oc auth can-i create projectrequest --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api4
Warning: resource 'projectrequests' is not namespace scoped in group 'project.openshift.io'
yes
$ oc auth can-i get project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api4
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
no
We need the admin:
$ oc adm policy add-cluster-role-to-user admin -z orchestrator-ocp-api4
clusterrole.rbac.authorization.k8s.io/admin added: "orchestrator-ocp-api4"
$ oc auth can-i get project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api4
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
yes
Using the cluster-admin will work but it will be able to do anything on the cluster, whereas the admin may have more restricted set of permissions
Alternatively, we could add a step to create a cluster role to get the project
$oc create clusterrole read-project --verb=get --resource=projects
clusterrole.rbac.authorization.k8s.io/read-project created
$ oc adm policy add-cluster-role-to-user read-project -z orchestrator-ocp-api4
clusterrole.rbac.authorization.k8s.io/read-project added: "orchestrator-ocp-api4"
$ oc auth can-i get project --as=system:serviceaccount:rhdh-operator:orchestrator-ocp-api4
Warning: resource 'projects' is not namespace scoped in group 'project.openshift.io'
yes
| oc -n $TARGET_NS patch secret "$WORKFLOW_NAME-creds" \ | ||
| --type merge -p "{ \ | ||
| \"stringData\": { \ | ||
| \"NOTIFICATIONS_BEARER_TOKEN\": \"$NOTIFICATIONS_BEARER_TOKEN\" \ |
There was a problem hiding this comment.
You missed a comma in the end here
\"NOTIFICATIONS_BEARER_TOKEN\": \"$NOTIFICATIONS_BEARER_TOKEN\" \ => \"NOTIFICATIONS_BEARER_TOKEN\": \"$NOTIFICATIONS_BEARER_TOKEN\", \
| oc -n $TARGET_NS patch secret "$WORKFLOW_NAME-creds" \ | ||
| --type merge -p "{ \ | ||
| \"stringData\": { \ | ||
| \"NOTIFICATIONS_BEARER_TOKEN\": \"$NOTIFICATIONS_BEARER_TOKEN\" \ | ||
| \"JIRA_API_TOKEN\": \"$JIRA_API_TOKEN\", \ | ||
| \"OCP_API_SERVER_TOKEN\": \"$OCP_API_SERVER_TOKEN\", \ | ||
| \"BACKSTAGE_NOTIFICATIONS_URL\": \"$BACKSTAGE_NOTIFICATIONS_URL\", \ | ||
| \"JIRA_URL\": \"$JIRA_URL\", \ | ||
| \"JIRA_USERNAME\": \"$JIRA_USERNAME\", \ | ||
| \"OCP_API_SERVER_URL\": \"$OCP_API_SERVER_URL\", \ | ||
| \"OCP_CONSOLE_URL\": \"$OCP_CONSOLE_URL\" \ | ||
| } \ |
There was a problem hiding this comment.
There is no need for the \ inside the json string in the end of the line:
... -p "{
\"stringData\": {
\"NOTIFICATIONS_BEARER_TOKEN\": \"$NOTIFICATIONS_BEARER_TOKEN\",
\"JIRA_API_TOKEN\": \"$JIRA_API_TOKEN\",
\"OCP_API_SERVER_TOKEN\": \"$OCP_API_SERVER_TOKEN\",
\"BACKSTAGE_NOTIFICATIONS_URL\": \"$BACKSTAGE_NOTIFICATIONS_URL\",
\"JIRA_URL\": \"$JIRA_URL\",
\"JIRA_USERNAME\": \"$JIRA_USERNAME\",
\"OCP_API_SERVER_URL\": \"$OCP_API_SERVER_URL\",
\"OCP_CONSOLE_URL\": \"$OCP_CONSOLE_URL\"
}
}"
works too
No description provided.