This topic gives you information about the API endpoints that the on-demand broker (ODB) accesses, and the minimum UAA authorities and corresponding permissions required for the ODB to operate correctly.
ODB accesses the following BOSH API endpoints during the service instance lifecycle:
API endpoint | Examples of usage in ODB |
---|---|
POST /deployments |
Create or update a service instance |
POST /deployments/DEPLOYMENT-NAME/errands/ERRAND-NAME/runs |
|
GET /deployments/DEPLOYMENT-NAME |
Passed as argument to the service adapter for generate-manifest and create-binding |
GET /deployments/DEPLOYMENT-NAME/vms?format=full |
Passed as argument to the service adapter for create-binding |
DELETE /deployments/DEPLOYMENT-NAME |
Delete a service instance |
GET /tasks/TASK-ID/output?type=result |
|
GET /tasks/TASK-ID |
Poll the BOSH Director until a task finishes, e.g. create, update, or delete a deployment |
GET /tasks?deployment=DEPLOYMENT-NAME |
Determine the last operation status and message for a service instance, e.g. ‘create in progress’. Used when creating, updating, deleting service instances. |
For information about BOSH API endpoints, see Director HTTP API in the BOSH documentation.
The actions that ODB needs to be able to perform are:
Modify:
bosh deploy
bosh delete-deployment
bosh run-errand
Read only:
bosh deployments
bosh vms
bosh tasks
The minimum UAA authority required by the BOSH Director to perform these actions is bosh.teams.TEAM-NAME.admin
.
Note A team admin cannot view or update the Director's cloud config, nor upload releases or stemcells.
For information on how to set up and use BOSH teams, see Using BOSH Teams in the BOSH documentation.
The bosh.teams.TEAM-NAME.admin
authority also allows the following actions, which currently are not used by ODB:
bosh start/stop/recreate
bosh cck
bosh logs
bosh releases
bosh stemcells
VMware tested ODB with the VMware IPsec add-on and it appears to work. The tests excluded the BOSH Director itself from IPsec ranges because the BOSH add-on cannot be applied to BOSH itself.
For how to install the VMware IPsec add-on, see Installing IPsec for VMware Tanzu.
ODB accesses the following CF API endpoints during the service instance lifecycle:
API endpoint | Examples of usage in ODB |
---|---|
GET /v2/info |
Identify CF API version to determine feature compatibility & availability |
GET /v2/services |
List all services to find our own service based on defined unique ID rather than GUID |
GET /v2/services/SERVICE-GUID/service_plans |
Find registered service plans for ODB service e.g. for calculating plan quota usage |
GET /v2/service_brokers |
Find service broker metadata by name during broker deregistration |
DELETE /v2/service_brokers/SERVICE-BROKER-GUID |
Delete ODB service broker during broker deregister errand |
GET /v2/service_plans/SERVICE-PLAN-GUID |
Identify service plan when upgrading an instance to trigger any lifecycle errands |
PUT /v2/service_plans/SERVICE-PLAN-GUID |
Deactivate service access prior to service deletion |
GET /v2/service_plans/SERVICE-PLAN-GUID/service_instances |
Find service instances for given plan when determining global quota and running startup checks |
GET /v2/service_instances/SERVICE-INSTANCE-GUID |
Determine service instance state to check an operation is not in progress before triggering an upgrade |
DELETE /v2/service_instances/SERVICE-INSTANCE-GUID |
Deleting a service instance during delete all service instances errand |
GET /v2/service_instances/SERVICE-INSTANCE-GUID/service_bindings |
Finding bindings for given service instance during delete all service instances errand |
GET /v2/service_instances/SERVICE-INSTANCE-GUID/service_keys |
Finding service keys for given service instance during delete all service instances errand |
DELETE /v2/apps/APP-GUID/service_bindings/SERVICE-BINDING-GUID |
Unbinding a service instance during delete all service instances errand |
DELETE /v2/service_keys/SERVICE-KEY-GUID |
Deleting a service key during delete all service instances errand |
For information about Cloud Foundry API endpoints, see the Cloud Foundry API documentation.
The actions that ODB needs to be able to perform are:
Modify:
cf enable-service-access
cf disable-service-access
cf create-service-broker
cf delete-service-broker
cf delete-service
cf unbind-service
cf delete-service-key
Read only:
cf api
cf marketplace
cf service-brokers
cf services
cf service
cf app
cf service-keys
The minimum UAA authority required by Cloud Foundry to perform these actions is cloud_controller.admin
. Admin is required as many operations are required to perform against all of the on-demand service instances across a foundation, regardless of org and space.
The Cloud Controller admin authority also allows the following actions, which currently are not used by ODB:
cf push
cf delete
cf start
cf restart
cf restage
cf stop
cf create-service-key
cf create-user-provided-service
cf update-user-provided-service
cf run-task
cf logs
cf ssh
cf scale
cf events