[Feature]: App Developer can see service binding credentials are volume mounted onto their workload containers

[tcdowney]

Blockers/Dependencies

• Blocker: [Feature]: App Developer can see K8s ServiceBindings created when a CFServiceBinding is created #506

Background

Cloud Native Buildpacks and some app frameworks (such as Spring Cloud Bindings) are adopting the K8s ServiceBinding spec model of volume mounted secrets. We currently are providing apps access to these via the VCAP_SERVICES environment variable (see this issue) for backwards compatibility reasons, but want to support these newer developments in the ecosystem as well.

We don't need to implement this ourselves. Theoretically any reconciler that adopts the spec can update Pod-specable workloads to do this. Let's look into using this Service Binding reconciler to do this and install it in our dev envs (Kind) and hack installation scripts. If we set up the spec.workload correctly in #506 this reconciler should be able to modify the StatefulSets that Eirini Controller is producing†. Then we can document that if developers/operators want this behavior they can use that reconciler or install a comparable one. If that all works well then it means we can avoid having to develop a partial implementation of the projection spec in our own controllers.

As an App Developer
I want service binding credentials to be projected into my running workloads via volume mounts
So that I my K8s Service Binding-aware apps can find service binding credentials in the way they expect

† Let's confirm there is no contention between this reconciler and Eirini Controller

---

Acceptance Criteria

Documentation

GIVEN I have a cluster available
WHEN I Follow our installation documentation
THEN I Can install a Service Binding reconciler and see the K8s ServiceBindings associated with our CFServiceBindings get reconciled by it

---

Functionality

GIVEN I have installed cf-k8s-controllers and have included a Service Binding reconciler
WHEN I bind a user-provided service instance to my app (cf bind-service MY_APP MY_INSTANCE)
THEN I see that eventually there exists a K8s ServiceBinding (done in #506)
AND I see that the credentials for that binding are volume mounted into the Pods for my app

---

Dev Notes

• https://github.com/vmware-labs/service-bindings
• https://github.com/servicebinding/spec#workload-projection
• We can use this Spring PetClinic app to test: https://github.com/vmware-labs/service-bindings/tree/main/samples/spring-petclinic

[tcdowney]

How I accepted this:

Deploying Spring PetClinic with kpack

I started with the same app that the Service Bindings reconciler codebase uses to test.

• Cloned Spring PetClinic
• Created the following CF app manifest in the app's directory to set the required env vars

  ---
  applications:
  - env:
    SPRING_PROFILES_ACTIVE: "mysql"

• Ran kubectl -n $(cf space s --guid) apply -f https://raw.githubusercontent.com/vmware-tanzu/servicebinding/4248dce6f9f7617662a098a3f2ef37f0c706e32c/samples/spring-petclinic/service.yaml to deploy a MySQL db I could use
• Created an UPSI with the same credentials as the db above:

  cf cups mysql -p '{"type":"mysql","provider":"mariadb","host":"spring-petclinic-db","port":"3306","database":"default","username":"user","password":"pass"}'`
  

• Pushed the app with no-start so that I could bind the service before staging: cf push spring-petclinic --no-start
• Bound the UPSI: cf bind-service spring-petclinic mysql
• Pushed the app cf push spring-petclinic (it failed due to there being competing maven and gradle config present Source with gradle and maven build systems fails paketo-buildpacks/java#423)
  • We can't set buildpack specific env vars until [Feature]: App Environment Variables should be available during staging #774 is done, so I manually deleted the maven dirs/files and pom.xml from the repo
• Pushed the app again..
• Built successfully, but failed to start: ERROR: failed to launch: determine start command: when there is no default process a command is required
• Apparently the gradle stuff was messed up and prevented the buildpack from being able to detect anything to run, so I restored the pom.xml and deleted the gradle files instead
• It worked!!

---

This is what my spring-petclinic working dir looked like after what I did to it:

✔ ~/workspace/spring-petclinic [main|✚ 6…1]
16:53 $ gst
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	deleted:    build.gradle
	deleted:    gradle/wrapper/gradle-wrapper.jar
	deleted:    gradle/wrapper/gradle-wrapper.properties
	deleted:    gradlew
	deleted:    gradlew.bat
	deleted:    settings.gradle

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	manifest.yml