Credentials Dependency issue should come from desired state not desired configuration

[rudchrisp]

Description:
Currently (and this understandably) one cannot change the referred secret (Service Manager Secret) used in a ServiceInstance.

Issue
In Day to Day operations often configurations like manifest/secret names are renamed and properties changed hence a very simple enhancement of this validation would be to not validate a change of:

btpAccessCredentialsSecret: <secretName>

Since this is only the actual "location" of the secret.
Instead the more flexible user friendly and easy to use solution not depending on the "reference" but on the actual "credential"

proposed solution
In the Admission Webhook instead of checking if the changed. (this should be ignored completly) Instead retrieve the secret content and hash256 it. If this hash deviates from the hash256 you had previously reject that secret. Since has256 is not revertible this would be secure.

With this simple enhancement of the hook the usability for day to day operations and user happiness would be improved dramatically.

Note: we had a lot of back and forth with secret management in our LOB and patterns convention changes scanner tools etc etc and this was a big pain.

[kerenlahav]

Hi @rudchrisp,

As you mentioned, the user can modify the content of the secret, so restricting changes to the secret name in the spec does not provide meaningful value. This restriction will be removed in the next release.

We will not validate the secret content itself, since it may change over time (for example, during credential rotation).

Please note that modifying the secret could affect the resource in unintended ways. For instance, switching to a secret from a different subaccount may lead to inconsistencies and other issues, so proceed with caution.

[rudchrisp]

@kerenlahav

Please note that modifying the secret could affect the resource in unintended ways. For instance, switching to a secret from a different subaccount may lead to inconsistencies and other issues, so proceed with caution.

Maybe it can be enhanced to parse the credential and see if the subaccount changed? or maybe if service manager instance id changed or similar? Is such a validation possible

Like only check the subject (I think the subaccount or some instance ID is maintained there right?) Maybe I am wrong here but the CN was an ID if I remember correctly.

So BTP operator can after 201 creation store the SubaccountID in the status of the instance and with that in the validation webhook do a quick comparison.

And if someone wants to avoid the validation the status can be deleted (so if the status section is emtpy it should just skip the subject validation)

I think this will bring the flexibility and also some resiliency regarding the issues you mentioned! I think a good middleground.

[kerenlahav]

The subaccount is not part of the credentials (only after fetching the token) and it is also does not guarantee safty because you can have multiple operator access instances in the same subaccount and you will encounter the same issues if credentials are replaced wrongly.
we cannot protect user mistakes in this case, just be careful :)

[rudchrisp]

Okay got it :) Documentation will take care of it and we will also make sure to explain this caveat within the teams! :)

[kerenlahav]

#607