Dashboard step1: pass thru support (without CF sso support)

[gberche-orange]

As a service author, I need dashboard returned by nested brokers to be returned to end users. I'm ok to handle authentication for the dashboard (e.g. https url with basic auth credentials in the url) and have it shared among users.

Out of scope:

• nested brokers to leverage CF sso feature https://docs.cloudfoundry.org/services/dashboard-sso.html

[gberche-orange]

See https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#body-4

a Service Broker that wishes to return dashboard_url for a Service Instance MUST return it with the initial response to the provision request, even if the service is provisioned asynchronously. If present, MUST be a string or null.

Asked clarification about behavior of GET /v2/service_instances/:instance_id w.r.t. dashboard_url returned in openservicebrokerapi/servicebroker#498 (comment)

Possible next steps:

Option 1: return inner broker dashboard in GET /v2/service_instances/:instance_id

1- have provisionning response return an initial (fake) dashboard url

• possibly pointing to a static page displaying a message such as "service instance being provisionned"
• possibly configured with a shield url such as https://shield-webui-m_8b04f44b-ae11-4a94-8dda-1d54fc1b1ce1.((/secrets/cloudfoundry_ops_domain)) i.e. configured as https://shield-webui-{0}.my-redactedt-ops-domain.com where {0} is the service instance guid.

2- implement the GET /v2/service_instances/:instance_id and return instances_retrievable in catalog service offering object

• for inner brokers supporting this endpoint (i.e. , just return provided value from inner broker GET /v2/service_instances/:instance_id endpoint
• for inner brokers not supporting this endpoint, we'd need to record this value returned from provisionning call. Beware some dashboard urls contain sensitive login/password data (such as rabbitmq broker)
  • in git templates repo in coab-depls/c_0a9018b8-7cb2-47c1-9542-0aceb8ca740a/template/
    • coab-vars.yml: currently holds CSIReq (as to share logic with Fetching a Service Instance endpoint)
    • coab-inner-cisresp.yml
  • in git secrets repo: in new file coab-depls/c_0a9018b8-7cb2-47c1-9542-0aceb8ca740a/coab-inner-cisr.yml (along with manifest file written by coa and watched by coab)
  • in credhub

Limitations of this design:

• a static shield url needs authentication and authorization addressed later in Set up git clone caches #42
• step 2 addresses rabbitmq dashboard: rabbitmq broker does not current supports instances_retrievable in version v54.0 from June 14th 2019, see https://github.com/pivotal-cf/cf-rabbitmq-multitenant-broker-release/search?q=instances_retrievable&unscoped_q=instances_retrievable

Likely blocked by CC conformance, see cloudfoundry/cloud_controller_ng#1390

Option 2: Return a dashboard URL served by COAB whose body response content includes a link to the dashboard URL of the inner broker

• record the inner broker dashboard_url returned from provisionning call. Beware some dashboard urls contain sensitive login/password data (such as rabbitmq broker)
  • in git templates repo in coab-depls/c_0a9018b8-7cb2-47c1-9542-0aceb8ca740a/template/
    • coab-vars.yml: currently holds CSIReq (as to share logic with Fetching a Service Instance endpoint)
    • coab-inner-cisresp.yml
  • in git secrets repo: in new file coab-depls/c_0a9018b8-7cb2-47c1-9542-0aceb8ca740a/coab-inner-cisr.yml (along with manifest file written by coa and watched by coab)
  • in credhub
• implement a new controller to endpoint /dashboards/{service-instance-guids)/ which returns HTML or Json with a list of dashboards
  • with a statically configured dashboard(s) if configured (e.g. url to shield )
  • with the inner broker dashboard url (e.g. rabbitmq dashboard)

In step 2, project this COAB dashboard with SSO

[gberche-orange]

Option 3: return dashboard url template expanded from service instance guid

https://shield-webui-m_8b04f44b-ae11-4a94-8dda-1d54fc1b1ce1.((/secrets/cloudfoundry_ops_domain)) i.e. configured as https://shield-webui-{0}.my-redactedt-ops-domain.com where {0} is the service instance guid.

Ability to include brokered service guid (planned in orange-cloudfoundry/osb-cmdb#15), or more generically Xpath expression to coab-vars.yml would enable to return a dashboard url for the cmdb users