Preflight checklist
Ory Network Project
No response
Describe your problem
Currently, when you define an OAuth2Client CRD with a reference to a Kubernetes Secret that does not exist yet or is not healthy, Hydra Maester generates random credentials, registers the client in Hydra, and creates its own Kubernetes Secret. This doesn't work well with the setup consisting of two kubernetes clusters in different regions, where we use Argo CD to simultaneously deploy a stack of Helm charts containing definitions for a Secret Manager secret (which is later populated by a pipeline with client credentials), an ExternalSecret operator, and an Ory Hydra client object.
Because the Secret Manager isn't instantly populated and the K8s Secret referenced in the client object does not exist yet, we get random IDs and credentials which forces us to recreate client objects after populating the secret in secret manager. Furthermore, the resulting K8s Secret cannot be overridden by the External Secrets Operator because it is locked by Hydra's ownership, But Maester doesn't watch the state of the secret after initially registering the client, so it doesn't matter that much. The controller wouldn't update the client even if the operator successfully updated the secret later.
In a setup with two clusters in different regions for a single environment, it is better to use the same credentials on both. This prevents forcing developers and testers to switch between different credentials when accessing the same app, depending on which region the load balancer routes their traffic to.
Describe your ideal solution
Possible solutions I've been considering:
-
A feature flag that disables the generation of random client credentials and Kubernetes Secrets if a secret reference is provided in the client object.
-
An additional unmanaged/external secret field. If a secret reference is defined in this field, the controller would wait for the secret to appear and simply log that it is missing, without generating a random client.
Workarounds or alternatives
You can force client object to wait for external secret to be healthy with sync waves annotations if youre using argo cd but it only works for initial automated sync.
Version
v0.0.42
Additional Context
No response
Preflight checklist
Ory Network Project
No response
Describe your problem
Currently, when you define an OAuth2Client CRD with a reference to a Kubernetes Secret that does not exist yet or is not healthy, Hydra Maester generates random credentials, registers the client in Hydra, and creates its own Kubernetes Secret. This doesn't work well with the setup consisting of two kubernetes clusters in different regions, where we use Argo CD to simultaneously deploy a stack of Helm charts containing definitions for a Secret Manager secret (which is later populated by a pipeline with client credentials), an ExternalSecret operator, and an Ory Hydra client object.
Because the Secret Manager isn't instantly populated and the K8s Secret referenced in the client object does not exist yet, we get random IDs and credentials which forces us to recreate client objects after populating the secret in secret manager. Furthermore, the resulting K8s Secret cannot be overridden by the External Secrets Operator because it is locked by Hydra's ownership, But Maester doesn't watch the state of the secret after initially registering the client, so it doesn't matter that much. The controller wouldn't update the client even if the operator successfully updated the secret later.
In a setup with two clusters in different regions for a single environment, it is better to use the same credentials on both. This prevents forcing developers and testers to switch between different credentials when accessing the same app, depending on which region the load balancer routes their traffic to.
Describe your ideal solution
Possible solutions I've been considering:
A feature flag that disables the generation of random client credentials and Kubernetes Secrets if a secret reference is provided in the client object.
An additional unmanaged/external secret field. If a secret reference is defined in this field, the controller would wait for the secret to appear and simply log that it is missing, without generating a random client.
Workarounds or alternatives
You can force client object to wait for external secret to be healthy with sync waves annotations if youre using argo cd but it only works for initial automated sync.
Version
v0.0.42
Additional Context
No response