Skip to content

Feature/dynamic service key credentials - #1929

Open
stiv03 wants to merge 5 commits into
masterfrom
feature/dynamic-service-key-credentials
Open

stiv03 wants to merge 5 commits into
masterfrom
feature/dynamic-service-key-credentials

Conversation

@stiv03

@stiv03 stiv03 commented Oct 19, 2026

Copy link
Copy Markdown
Contributor

No description provided.

Extend the v3 DynamicResolvableParametersFactory to scan each resource's
service-keys[].config for {ds/...} credential references, in addition to
the existing top-level parameter/property scan. Scoped recursion only
into service-keys[].config, preserving the existing depth-one contract
for all other parameters.
Add ServiceKeyCredentialResolver, which replaces
{ds/<resource>/service-keys.<key>.credentials.<field>} references in a
service key's credentials by reading the referenced (already created)
service key's credentials from the Cloud Controller and extracting the
addressed field. Missing fields fail loudly with a clear message.

Wire it in via a new idempotent ResolveServiceKeyCredentialReferencesStep,
inserted in create-service-key.bpmn between the operation-in-progress
check and createServiceKey, so a referenced resource's key (guaranteed to
be in an earlier, already-completed batch by processed-after) is read back
just before the consuming key is created.
ResolveServiceKeyCredentialReferencesStep now builds the
relationship->service-instance-name map from the deployment descriptor,
using each resource's service-name parameter (falling back to the
resource name). Previously it passed an empty map, so the credential
read-back used the resource name as the service instance name and failed
for resources whose service-name differs from their resource name.
@stiv03
stiv03 force-pushed the feature/dynamic-service-key-credentials branch from 411c202 to 12700f7 Compare October 19, 2026 08:59
Extend the dynamic service-key credential feature to a module's
service-binding parameters (requires[].parameters.config), not only
service-keys[].config. Factor the map-level resolution out of
ServiceKeyCredentialResolver into resolveReferencesInMap, and add an
idempotent ResolveBindingCredentialReferencesStep that rewrites
SERVICE_BINDING_PARAMETERS just before BindServiceToApplicationStep,
wired into manage-app-service-bindings.bpmn on the bind path (the POLL
re-entry edge still targets the bind task directly; resolution is a
no-op once no references remain).

This supports the client scenario of injecting a produced service key's
credential (e.g. ZTIS issuer/subject) into another service's binding
config. The reference must name a service key; a bare managed-service
reference has no retrievable credential output in CF.
The binding-resolution step runs inside the manageAppServiceBindingSubProcess
Flowable sub-process, which does not inherit COMPLETE_DEPLOYMENT_DESCRIPTOR.
Build the relationship->service-instance-name map from Variables.SERVICES_TO_BIND
(each CloudServiceInstanceExtended carries getResourceName() and getName()),
which is passed into the sub-process and already precomputes the resolved CF
service instance names. The referenced resource must be among the module's
required dependencies so it appears in SERVICES_TO_BIND.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant