Add controller field to SecretStore to allow for multiple ambient credential deployments

[mcavoyk]

Is your feature request related to a problem? Please describe.
Only one controller using "ambient" credentials (credentials which make up the controllers environment variables or volumes) can be used per namespace/cluster. The controller with ambient creds has no method of scoping what SecretStore's the controller is owner of.

Describe the solution you'd like
Add controller field to SecretStore types which can provide an optional scoping mechanism when either using multiple secret-managers with ambient credentials or mixed ambient/explicit creds. An example would be to deploy a controller with AWS IRSA authentication which has ambient creds for aws secret manager and/or vault secret store with AWS auth, but this controller is scoped to only SecretStore's with "aws" string in the controller field. Another secret-manager could be deployed to cover explicit default controllers.

Describe alternatives you've considered
One other solution is to disallow the use of ambient credentials and force explicit credentials. This may not be preferred as cloud providers can offer secure ways to manage ambient credentials for their systems (like AWS IRSA #77) .

/kind feature

[mcavoyk]

I have mixed feelings around ambient credentials. They are a bit tricky to test (often times we have to rely on the specific SDK's "just working" and set the ENV vars they expect), but can be really useful from a deployment perspective. Having to deploy multiple secret-managers per cluster to deal with multiple sets of ambient creds feels like the wrong solution.

I think another reasonable option here is as mentioned is to force explicit and disallow ambient, but then to also offer "serviceaccount selector" in cases where a Kubernetes service account token is used as authentication (like AWS IRSA, Vault Kubernetes auth, etc).