[Feature]: App Developer can see K8s `ServiceBinding`s created when a `CFServiceBinding` is created

tcdowney commented 2 years ago

Blockers/Dependencies

Could be useful to do https://github.com/cloudfoundry/cf-k8s-controllers/issues/746 first

Background

As an App Developer I want there to be K8s ServiceBindings for any CFServiceBindings I create So that I can interoperate with the larger K8s services ecosystem

Acceptance Criteria

GIVEN I have a applied a CFServiceBinding to my cluster WHEN I kubectl get servicebindings -n NAMESPACE_NAME THEN I see an instance of a K8s ServiceBinding associated with the CFServiceBinding I created

---
apiVersion: servicebinding.io/v1alpha3
kind: ServiceBinding
metadata:
  name: cf-binding-683161a5-a8f8-4107-9179-9e47489b0326 # service binding GUID
  namespace: e5f8f1eb-7fb9-4285-90d8-947de5859e05 # space GUID, same as for app and service instance
  labels:
    services.cloudfoundry.org/service-binding-guid: 683161a5-a8f8-4107-9179-9e47489b0326
    workloads.cloudfoundry.org/app-guid: 3bd795f2-8f50-4b75-b443-37b6e5dca393 # app GUID
    services.cloudfoundry.org/service-credential-binding-type: app
  ownerReferences:
    - apiVersion: services.cloudfoundry.org/v1alpha1
      kind: CFServiceBinding
      name: 683161a5-a8f8-4107-9179-9e47489b0326
      uid: 497641ec-0818-4865-b701-94daa3ed2499
spec:
  name: developer-provided-name
  provider: user-provided
  type: user-provided
  service:
    apiVersion: services.cloudfoundry.org/v1alpha1
    kind: CFServiceBinding
    name: 683161a5-a8f8-4107-9179-9e47489b0326 # service binding GUID
  workload:
    apiVersion: apps/v1
    kind: StatefulSet
    selector: <label selector for the app-guid> (could also use the name if that is deterministic)

Dev Notes

Remember ownerReferences/status/labels
We prefix the name with cf-binding- like we are in https://github.com/cloudfoundry/cf-k8s-controllers/issues/724
Can we install the CRD from here: https://github.com/servicebinding/spec/blob/main/servicebinding.io_servicebindings.yaml ? The install-on-kind.sh script should do this.

Resources:

Read through and understand the ServiceBindings portion of the K8s Service Bindings Spec: https://github.com/servicebinding/spec#service-binding
- Schema: https://github.com/servicebinding/spec#resource-type-schema-1
Related Exploration: https://github.com/cloudfoundry/cf-k8s-controllers/issues/367

tcdowney commented 2 years ago

@akrishna90 I'm trying to think back to an earlier conversation we had a few weeks ago. In the case of K8s ServiceBindings did you recommend we set provider to user-provided?

akrishna90 commented 2 years ago

If we do it then any concrete implementation of the Service Binding spec would override provider value that is set on the secret. It doesn't do any harm to set it on the binding as I don't see other implementations depending on that value. It makes our code simpler while filtering for user-provided service bindings.

I am saying this keeping in mind that type value on the binding/secret has an impact on how it is used later - https://github.com/spring-cloud/spring-cloud-bindings

IIRC, Isn't the type also user-provided?

tcdowney commented 2 years ago

Thanks @akrishna90 for the additional context. 🙂 I added type as well.

tcdowney commented 2 years ago

I updated the spec.workload section to directly reference the StatefulSets that Eirini will be producing with some flexibility around whether or not we refer to them by name or by an app-guid label selector. I think the label selector approach sounds appealing, but I'm wondering if there are any security concerns there around someone labeling other StatefulSets with a different app's GUID. 🤔 Might not be an issue since this all exists in the same namespace anyway and presumably they could get access in other ways by just volume mounting those binding secrets directly themselves. (cc @akrishna90 @julian-hj )

Also, I recognize that targeting the StatefulSet directly will break some encapsulation around what Eirini (or other future runtimes) are doing under the hood, but it feels like something the can iterate on over time. In the future if we have a different intermediate resource than the Eirini LRP we could point at that directly. Even if it's not Pod-specable we could use ClusterWorkloadResourceMapping resource to tell a Service Binding reconciler how to manipulate it. (cc @matt-royal about the future runtimes thoughts)

cloudfoundry / korifi