[Feature]: App Developer can see credentials from Service Bindings are projected onto kpack staging Pods

[tcdowney]

Blockers/Dependencies

No response

Background

As an App Developer
I want Credentials from Service Bindings for User-provided Service Instances to be accessible to kpack Pods when staging my app
So that service credential binding is available to buildpacks that might make use of it during staging

---

Acceptance Criteria

GIVEN I have one or more CFServiceBindings bindings bound to an app
WHEN I initiate a new Build for my app
THEN I see the CFServiceBindings that are referred to by the spec.services of the Kpack Image for that app/build. See: https://github.com/pivotal/kpack/blob/main/docs/servicebindings.md
AND I can see that the credentials in the UPSI/CFServiceBinding Secrets are volume mounted in the Kpack staging Pod when the build executes

---

Dev Notes

Resources:

• Related Exploration: [Explore]: Spike out User Provided Service Instances Support Using Kubernetes Service Bindings for Runtime #367
• UPSI Proposal Doc
• https://github.com/pivotal/kpack/blob/main/docs/servicebindings.md

[julian-hj]

I added an issue to kpack here to point out that the ProvisionedService binding is not very well implemented, and doesn't log errors.

For now, we will just bind the secret directly to the Image, since it doesn't seem that binding to CFServiceBindings will work very well.

[julian-hj]

Note that Matt McNew opened this PR to allow us to grant kpack access to our ServiceBindings without reaching into kpack: buildpacks-community/kpack#922

[tcdowney]

Wow that was fast. Hypothetically, one long term benefit to actually using the CFServiceInstance over directly using Secrets I think is that it would more easily support credential rotation for managed services. I still think what we've done with binding the Secret directly is probably fine for now considering we're making new kpack Images per build and CF devs are already well acquainted with needing to do a cf restage after bindings are changed/added.

[gnovv]

There are small issues we noted with the initial implementation:

1- In order to have the secret be ingested by kpack we had to add the type key to the Data with the value user-provided. We decided to do so by adding/overwriting the key on the shim side when the secret is created. Effectively this makes it so that the type field cannot be set by cf cups

2- There is a "closed door" problem with eventual consistency around the builds. If the secrets and bindings are created at the same time as the CFBuild- the first reconcile will silently complete potentially without the secrets. Since we never rebuild once a build is completed, the kpack image will never be updated unless you cf restage

[tcdowney]

If the secrets and bindings are created at the same time as the CFBuild- the first reconcile will silently complete potentially without the secrets. Since we never rebuild once a build is completed, the kpack image will never be updated unless you cf restage

I think this is fine. I think the sequence of events in cf push will make this case very unlikely if not impossible (app is configured, then package is uploaded, then build is created). If you're doing the service binding concurrently / shortly after cf push then the existing behavior is to require a cf restage anyway.