Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
cmoulliard opened this issue Nov 16, 2018 · 13 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@cmoulliard
Copy link

cmoulliard commented Nov 16, 2018

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 cmoulliard added the bug label Nov 16, 2018
@cmoulliard
Copy link
Author

cmoulliard commented Nov 16, 2018

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
Copy link
Author

Is this error related to https://bugzilla.redhat.com/show_bug.cgi?id=1541461 ?

@cmoulliard
Copy link
Author

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

@cmoulliard
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

jmrodri commented Nov 19, 2018

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
Copy link
Contributor

jmrodri commented Nov 19, 2018

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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-ci-robot openshift-ci-robot added kind/bug Categorizes issue or PR as related to a bug. and removed bug labels Apr 14, 2019
@openshift-bot
Copy link

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

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 6, 2020
@jmrodri
Copy link
Contributor

jmrodri commented Sep 20, 2020

/close

@openshift-ci-robot
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

4 participants