Skip to content

Latest commit

 

History

History
204 lines (161 loc) · 6.35 KB

11-disabling-project-self-provisioning.adoc

File metadata and controls

204 lines (161 loc) · 6.35 KB
Raw

Disabling Project Self-Provisioning

OpenShift, by default, allows authenticated users to create Projects to logically house their applications. This feature enables admins to provide a "self service" feature that was popularized by the advent of the "PaaS" (Platform as a Service) model.

This feature may not be suitable for all situations, and many administrators may want to have more control over Projects and who (if anyone) can create them. Some of these use cases may be:

  • Environment Protection - Administrators may not want Projects getting created without their knowledge.

  • Resource Allocation - Administrator may want fine grained control over resource allocation (i.e. "I don’t want to overcommit")

  • Quota flexibility - Default quotas may be set, but Administrators may want to specify additional quotas (or fewer) depending on the Project scope.

  • Accounting and Chargeback - In a multitenant system, there may be a need to do accounting and chargeback.

  • General Administrative Control - Administrators may want total control in what goes in an environment.

Examine the Clusterrolebinding

In order to examine the clusterrolebinding for self-provisioners; you need to be kubeadmin.

View the self-provisioners cluster role binding usage by running the oc describe command:

oc describe clusterrolebinding.rbac self-provisioners

You should see the following output:

Name:         self-provisioners
Labels:       <none>
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  self-provisioner
Subjects:
  Kind   Name                        Namespace
  ----   ----                        ---------
  Group  system:authenticated:oauth

Here, it’s saying that the group system:authenticated:oauth (which is a group that every user that has authenticated is a part of, by default), is bound to the self-provisioners role. This role is a built-in role in OpenShift that allows the users to create projects.

To view the configuration itself, inspect the yaml by running the following:

oc get clusterrolebinding.rbac self-provisioners -o yaml

The configuration should look something like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2022-04-22T06:33:13Z"
  name: self-provisioners
  resourceVersion: "9884"
  uid: 9d63853f-287a-4895-bd89-c169184afdfd
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: self-provisioner
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated:oauth

Removing Self Provisioning Projects

To remove the self-provisioner cluster role from the group system:authenticated:oauth you need to remove that group from the role binding.

oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

Automatic updates reset the cluster roles to a default state. In order to disable this, you need to set the annotation rbac.authorization.kubernetes.io/autoupdate to false by running:

oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

View the new configuration:

oc get clusterrolebinding.rbac self-provisioners -o yaml

It should now have no subjects in the YAML. It should look something like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "false"
  creationTimestamp: "2022-04-22T06:33:13Z"
  name: self-provisioners
  resourceVersion: "1624527"
  uid: 9d63853f-287a-4895-bd89-c169184afdfd
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: self-provisioner

Test this by logging in as fancyuser1 and try to create a project.

oc login -u fancyuser1 -p Op#nSh1ft
oc new-project fancyuserproject

You should see an error message:

Error from server (Forbidden): You may not request a new project via this API.

Login as the admin user for the next exercise.

Customizing the request message

Now any time a user tries to create a project they will be greeted with the same message You may not request a new project via this API. You can customize this message to give a more meaningful call to action.

For example, you can have the users submit a ticket requesting a project. We can do this by changing the text given, to include instructions:

oc patch --type=merge project.config.openshift.io cluster -p '{"spec":{"projectRequestMessage":"Please visit https://ticket.example.com to request a project"}}'

Here, you are adding the projectRequestMessage and the value Please visit https://ticket.example.com to request a project to the specification.

Before you can see this new message, you’ll need to wait for the apiserver application to rollout the changes. This can take some time to rollout, especially on a busy cluster.

sleep 30
oc rollout status -n  openshift-apiserver deploy/apiserver

Now, the user will get this message when trying to create a project. Test this by becoming the fancyuser1 user.

oc login -u fancyuser1 -p Op#nSh1ft

And try to create a project.

oc new-project fancyuserproject

You should see the following message:

Error from server (Forbidden): Please visit https://ticket.example.com to request a project

Clean Up

Make sure you login as kubeadmin for the next lab.

Other labs may require the self-provisioners role, so let’s undo what we did:

oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects":[{"apiGroup":"rbac.authorization.k8s.io","kind":"Group","name":"system:authenticated:oauth"}]}'
oc patch clusterrolebinding.rbac self-provisioners -p '{"metadata":{"annotations":{"rbac.authorization.kubernetes.io/autoupdate":"true"}}}'
oc patch --type=json project.config.openshift.io cluster -p '[{"op": "remove", "path": "/spec/projectRequestMessage"}]'