Dynamic dashboard permission provisionning

[gberche-orange]

Expected behavior

As a service broker author

• in order to provide access a brokered service (e.g. GCP CloudSQL) whose provider has an existing authN authZ system (e.g. GCP workspace identity) while not handling specific authN and authZ from each client platform (CF SSO, K8S authZ api, ...)
• I need osb-cmdb to provide me with a single unified API to dynamically provision authN and authZ for users of each client platform.

Alternatives for such unified api

• Leverage OSB API:
  1. A service binding on the original service definition (e.g. "cloudsql") with params
     • pro: consistent model with service binding concepts
     • pro: simpler for service broker: less boilerplate
     • con: service binding update isn't yet supported by CF, therefore dashboard permission updates require unbind/rebind, potentially adding latency to UX
  2. A new distinct service definition (e.g. "cloudsql-dashboard-permissions") that cross references the original service (eg "cloudsql")
     • con: harder to extend off-the-shelf service brokers (e.g. cloud-service-broker GCP brokerpak) without forking them
     • however, Orange is still likely to fork the GCP brokerpak to adding customizations/governance/orange-ecosystem-integration

The following diagram illustrates option i) :

 With: * 10: OIDC user_info flow to get corporate id (CUID in orange). Calls the OIDC endpoint provided by platform in ` X-Api-Info-Location`. See https://github.com/orange-cloudfoundry/osb-cmdb#dashboard-authn-and-authz-support-wip for full details * 12: CF and K8S specific endpoints to fetch user authZ for a service instance. See https://github.com/orange-cloudfoundry/osb-cmdb#dashboard-authz-using-cf-service-instance-permission for full details.

For reference, the following diagram illustrates option ii) :


Observed behavior

Osb-cmdb does not yet support this use-case.

Affected release

Reproduced on version x.y -->

[redorff]

Notes about the schema here above:

• following OSB API, step [5] is returning a "_dashboardurl". What does CMDB do with it?
• steps [17] and [18] are showing self calling arrows... what is technically implied there?

[gberche-orange]

following OSB API, step [5] is returning a "dashboard_url". What does CMDB do with it? cmdb stores it and redirects the user to it in step [15]

steps [17] and [18] are showing self calling arrows... what is technically implied there? This is authenticating and authorizing users with the service provider IAM (which was configured with dashboard permission in step [13]

I've updated the issue to favor service bindings

thanks @redorff for the offline feedback you and your team gave me and further design elements we discussed together

• finding the right balance balance for expiration of dashboard permission is subtle:
  • dashboard permission provisionning time may routinely take 30s latency. This may damage user-experience if that much latency is paid too frequently, i.e. if expiration time is too short (say minutes or hours)
  • if expiration time is too high, then security/human-errors risks of using unrevoked permissions
    • might be mitigated with additional explicit osb-cmdb UX, e.g.
      • cf update-service my-gcp-instance -c { x-osb-cmdb:{ revoke-dashboard-permissions-for-guid=userguid } } }
      • cf update-service my-gcp-instance -c { x-osb-cmdb:{ revoke-all-dashboard-permissions=true} } }
  • expiration time needs to be larger than potiential unavailability time of osb-cmdb (as to avoid osb-cmdb being involved in data-plane SLAs, e.g. a scenario where osb-cmdb is down and app operators can not access their service dashboard as they can't renew their dashboard permissions)

[gberche-orange]

Refined README.md doc related to K8S API used in sequence diagram interation 12 in https://github.com/orange-cloudfoundry/osb-cmdb/commit/b118357759ed16b7c8b7e9f40dfb0f255cc6f9bd

The SubjectAccessReview API call would require a service account with a role binding granting create permission for the subjectaccessreviews resource.

While admin accounts typically have this role granted, a service account with only this role would be provisionned instead for osb-cmdb in each K8S client platform

K8S java clients support the SubjectAccessReview endpoints:

• official kubernetes-client/java: https://github.com/kubernetes-client/java/search?q=subjectaccessreview
• fabric8io/kubernetes-client: https://github.com/fabric8io/kubernetes-client/search?q=subjectaccessreview