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.

BOSH API Endpoints

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
  • Register or de-register the on-demand broker with the Cloud Controller
  • Run smoke tests
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
  • Check a task was successful (i.e. the exit code was zero)
  • Get list of VMs
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.

BOSH UAA Permissions

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.

Unused BOSH permissions

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 IPsec

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.

CF API Endpoints

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.

Cloud Foundry UAA Permissions

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.

Unused Cloud Foundry permissions

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
  • Route and domain management
  • Space management
  • Org management
  • CLI plugin management
check-circle-line exclamation-circle-line close-line
Scroll to top icon