openshift/ansible-service-broker

Error provisioning ServiceInstance of ClusterServiceClass - Status: 403 - Description: User does not have sufficient permissions

cmoulliard opened this issue · 13 comments

cmoulliard commented

Version

minishift : v1.26
okd : 3.11
oab : v3.11

Bug

When an operator creates a serviceInstance, then the following error is reported

Error provisioning ServiceInstance of ClusterServiceClass (K8S: 
"1dda1477cace09730bd8ed7a6505607e" ExternalName: "dh-postgresql-apb") at
 ClusterServiceBroker "openshift-automation-service-broker": Status: 403; ErrorMessage: <nil>; 
Description: User does not have sufficient permissions; ResponseError: <nil>

The ServiceAccount used by the operator within its component-operator namespace has been granted to clusterrole - rbac as defined here : https://github.com/snowdrop/component-operator-demo/blob/master/resources/cluster-rbac.yaml

cmoulliard commented

Is this error due to the fact that the userInfo is created as such

  userInfo:
    groups:
    - system:serviceaccounts
    - system:serviceaccounts:component-operator
    - system:authenticated
    uid: ''
    username: 'system:serviceaccount:component-operator:component-operator'

without this section which is created when a user authenticated on the UI has created a service ?

    extra:
      scopes.authorization.openshift.io:
      - 'user:full'

What is the purpose of userInfo ? Do we have to specify it when we create a serviceInstance using a controller/operator ?

cmoulliard commented

@jmontleon @shawn-hurley Can you help me on concerning this issue please ?

cmoulliard commented

I can resolve this issue if I add to the ClusterRole definition linked to the operator serviceaccount, this missing apiGroups/resources/verbs

- apiGroups:
  - automationbroker.io
  resources:
  - "*"
  verbs:
  - "*"

Can you explain why we need for a serviceaccount such additional rule ?

cmoulliard commented

The trick reported before doesn't work for okd-3.10 and OABroker - docker.io/ansibleplaybookbundle/origin-ansible-service-broker:ansible-service-broker-1.2.17-1

jmrodri commented

If you control the broker installation you can configure it to auto_escalate which will skip the check. This is great for a development broker but probably not the best for a production broker as you will be elevating apbs with privilege. The operator serviceaccount needs to have the edit or cluster-admin role in order to be able to used by the broker to accomplish the provisioning tasks.

jmrodri commented

Basically the user needs to be able to perform the action on the target namespace. Otherwise, the broker is limited in what it can do from a security perspective. I believe it's edit on the target namespace is the minimum that the user needs.

cmoulliard commented

you can configure it to auto_escalate which will skip the check

Is this option documented somewhere like what you describe in this comment ?

cmoulliard commented

I believe it's edit on the target namespace is the minimum that the user needs.

Can you then add such remark to the documentation of OAB please ?

cmoulliard commented

auto_escalate

Admin doc is not really verbose about the purpose of auto_escalate and in fact could confuse the users as it seems that it should only be used to deploy APB playbooks and not at all to by pass the issue about a serviceaccount's user requesting to create a serviceinstance

 auto_escalate: true # will allow all users to deploy the approved APB. Could be false if the administrator would still like the broker to check the permissions.
openshift-bot commented

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

jmrodri commented

/close

openshift-ci-robot commented

@jmrodri: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.