Support for cloud-specific private endpoints

[gberche-orange]

Some managed services are not exposed over the internet, but rather through private endpoints in the cloud provider.

See for example in GCP, https://cloud.google.com/vpc/docs/configure-private-service-connect-producer on how a managed service provider would expose such private endpoints.

The consumer then needs to perform some networking operations to consume such private endpoints (in GCP see https://cloud.google.com/vpc/docs/configure-private-service-connect-services)

Currently, the service binding specifications don't yet support such use-cases during

• service provisioning: the Provisioned Service may need to provide metadata necessary for the service producers (such as the cloud project id or network ids that will be used to consume the provisioned service)
• provisioned services standard metadata: well known secret entries don't yet include such private endpoints, typically SERVICE_ATTACHMENT: the URI of the service producer's service attachment. For example: projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME

spec/README.md

Lines 140 to 152 in b5d6755

	## Well-known Secret Entries
	Other than the recommended `type` and `provider` entries, there are no other reserved `Secret` entries. In the interests of consistency, if a `Secret` includes any of the following entry names, the entry value **MUST** meet the specified requirements:
	| Name | Requirements
	| ---- | ------------
	| `host` | A DNS-resolvable host name or IP address
	| `port` | A valid port number
	| `uri` | A valid URI as defined by [RFC3986](https://tools.ietf.org/html/rfc3986)
	| `username` | A string-based username credential
	| `password` | A string-based password credential
	| `certificates` | A collection of PEM-encoded X.509 public certificates, representing a certificate chain used to trust TLS connections
	| `private-key` | A PEM-encoded private key used in mTLS client authentication

BTW, here is related prior art (2019) in the service broker api to support similar use case, see cloudfoundry/servicebroker#632
https://github.com/cloudfoundry/servicebroker/blob/ef303a9559f1fb3815ac9d47b27439058bf3fa7c/spec.md?plain=1#L1338-L1344

In some cases, the creation of a Service Binding has to be accompanied by
additional network configuration. This could be the configuration of a firewall
or a load balancer or it could be the setup of a network tunnel or a VPN
connection.
To enable the Platform to do this in a service agnostic way, the Service Broker
SHOULD provide the endpoints that the Application uses to connect to the service
alongside the binding credentials.

Would it make sense to add explicit support in the service binding specs some of the major cloud provider private endpoints formats ?

Could it then make sense for implementations of the service binding specs to add cloud-specific processing in the workload projection ?

Some managed service provider operators implement this cloud-specific workload projection, such as mongodb atlas

• see https://www.mongodb.com/docs/atlas/operator/current/atlasprivateendpoint-custom-resource/
  • with background into https://www.mongodb.com/docs/atlas/security-private-endpoint/ and https://www.mongodb.com/docs/atlas/security-private-endpoint/#private-endpoint-concepts

Here is my view of the benefits that such support could bring to service binding and the community overall

K8s Operator implementing cloud-specific network provisionning	pro	cons
Service Providers (e.g. mongodb atlas)	Faster initial time to market	Duplicated code/effort among service providers and supported public clouds
Service Binding Impl	Can be leveraged for multiple service offerings. For platform owners, better control of cloud credentials and actions performed on their cloud tenants.	Dependency on adoption/maintenance of service binding specs/impls

Are you instead aware of alternative crosscutting OSS K8S operator that could instead handle such cloud-specific workload projection ?

• https://github.com/anynines/klutchio/ seems to plan some similar support, albeit not yet being publicly detailed

[nebhale]

Hey @gberche-orange I wanted to check in and let you know that I’ve seen this. Give me a couple of days to fully digest it and I’ll get back to you.

[gberche-orange]

thanks @nebhale for your prompt acknowledgement, I've refined the issue body with typo fixes, additional background and thoughts.

[gberche-orange]

@nebhale ping