The Ansible service broker has three main use cases from an administration perspective. Below we will describe the main use cases and discuss the configurations for the broker that would make sense of each one.
Note: If you are running on a OpenShift 3.6 Cluster you can only use auto_escalate: true
More information about the broker configuration can be found here
The three main use cases are:
The heavy multi-tenant deployment is defined by the having many users with many different permission sets. This environments canonical example is OpenShift Online. This deployment requires that the broker will enforce the user's permissions when attempting to run APBs for a target name space or project. The configuration values that matter are openshift.sandbox_role
and broker.auto_escalate
. The sandbox_role
will be used to determine what permissions the user will need to run. The auto_escalate
will tell the broker whether or not to run with out checking the user's permissions. Note: auto_escalate
being set to false is the default configuration for the broker
...
openshift:
...
sandbox_role: "edit"
broker:
...
auto_escalate: false
The light multi-tenant deployment is defined by having powerful end users that are expected to have high levels of permissions. This deployment will give the cluster administrator the choice if they want the broker to check the permissions. In this scenario, we suggest that an audit is done of the APBs that will be available. The administrator can use the registry filter configuration to explicitly remove or approve APBs.
registry:
- ...
white_list:
- "^approved-APB$"
black_list:
- "removed-APB$"
...
openshift:
...
sandbox_role: "edit"
broker:
...
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.
The very limited tenant deployment is defined by having end users with very limited rights. This deployment will use the broker to give these users the ability to run certain actions that the cluster administrator has blessed. This will allow the cluster administrator to expose slightly more functionality without giving away more permissions than they would like. Here the cluster administrator should do a thorough analysis of the APBs that they will be offering.
registry:
- ...
white_list:
- "^approved-APB$"
black_list:
- "removed-APB$"
...
openshift:
...
sandbox_role: "edit"
broker:
...
auto_escalate: true