scothis
commented
2 years ago Hi @mamachanko
This is a question that has come up a few times, most recently on slack. The current thinking boils down to this: because the service binding isn't responsible for creating credentials, it's also not responsible for rotating them. Likewise, because the service binding is responsible for delivering those credentials it's is responsible for updating the delivered credentials when there is a change. What that means in practice depends on the behavior of the provisioned service and workload.
If a provisioned service exposes a new secret, that new secret name will be projected into the workload and likely trigger a pod rollout based on the semantics of the workload. If a provisioned service updates the content of an existing secret the service binding will do nothing as it doesn't observe the content of the secret. The updated credentials will appear on the filesystem for the workload. Depending on the workload's implementation it may notice the updated values and react to them, or pick them up the next time the pod starts.
mamachanko
One of the nice things about service bindings is that service providers can ensure good credentials. That's assuming that the service provider is in fact the party that mints the credentials. It takes the burden of service consumers.
However, all credentials should be rotated eventually if possible. But even if the service provider prepared a new set of credentials for the consumer it can't prompt the consumer.
I was wondering whether credential rotation should or will be considered by the spec? On the other hand I imagine this to get complicated really quickly and best left to organisations or specific implementations.