Does parametersFrom work with automatic credential rotation?

[lanthoor]

Premise

I have a ServiceInstance (called instance-a) and its ServiceBinding (called binding-a) that are created using the SAP BTP Service Operator.

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: instance-a
  namespace: instance-a-namespace
spec:
  serviceOfferingName: service-a
  servicePlanName: plan-a
  externalName: instance-a
  parameters:
    param: value-a

---

apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: binding-a
  namespace: namespace-b
spec:
  serviceInstanceName: instance-a
  serviceInstnaceNamespace: namespace-a
  externalName: binding-a
  secretName: secret-a
  credentialsRotationPolicy:
    enabled: true
    rotationFrequency: 600h
    rotatedBindingTTL: 1680h

I have another ServiceInstance (called instance-b) that uses parametersFrom to read values from the Secret generated from the above ServiceBinding (binding-a).

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: instance-b
  namespace: namespace-b
spec:
  serviceOfferingName: service-b
  servicePlanName: plan-b
  externalName: instance-b
  parameters:
    param: value-b
  parametersFrom:
    - secretKeyRef:
        name: secret-a
        key: key-a

Question

A new Secret will be created based on the rotation policy I've defined in binding-a and the old one will be moved to a suffixed Secret till TTL expires. Will the ServiceInstance with the name instance-b automatically pick up the new values from the Secret or do we have to perform some action to make it happen?

[kerenlahav]

Hi @lanthoor
The instance will not be updated automatically when the secret changes, you need to update the instance's spec in order to use the new paramerts from the secret.
The is an open feature request about it that is currently being evaluated.
Thanks

[loewenstein]

I would indeed argue that the btp-service-operator in supporting parametersFrom should watch those secrets for changes and update the instance or binding accordingly.

I can see how this could be breaking and I could also see the use case of keeping the parameters once read from a secret. So this should probably be configurable.

Where could I track the feature request you mentioned?

[kerenlahav]

https://jira.tools.sap/browse/SAPBTPCFS-11799

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[MarcusNotheis]

Feature Request is still open, adding this comment to prevent automatic issue closing.

[corey-aloia]

Just to add another use case: I have a saas registry where I want to change the display name. The service instance gets the parameters from a secret like:

  parametersFrom:
  - secretKeyRef:
      key: parameters
      name: my-secret

I was able to actually use the "customTags" section to force an upgrade:

spec:
  customTags:
  - 'checksum/secret: 123'

but this seems like a hack. And it is also not usable due to not owning the charts... was just a poc

Currently it seems that teammates will be tempted to delete the serviceinstances and recreate when wanting to change. Something that may not be possible if having multiple subcribers to a saas registry service

[loewenstein-sap]

Could you please consider prioritizing this and solve the parametersFrom case. This is not only a problem of service instance interdependencies. Even a simple service instance that needs a confidential parameter cannot be updated at the moment without touching an arbitrary property in the spec of the instance.