JWTOIDCAuthEngineConfig does not Reconcile correctly after creating CR without OIDCCredentials #225
Comments
|
Try using the latest version of the operator (you may need to update the CRDs). That Here are the CR defaults from my test... apiVersion: redhatcop.redhat.io/v1alpha1
kind: JWTOIDCAuthEngineConfig
metadata:
name: gitlab-oidc-config
namespace: test-vault-config-operator
spec:
JWKSCAPEM: ""
JWKSURL: ""
OIDCClientID: ""
OIDCDiscoveryCAPEM: ""
OIDCDiscoveryURL: https://gitlab.example.com
OIDCResponseMode: ""
boundIssuer: https://gitlab.example.com
defaultRole: ""
namespaceInState: true
path: gitlab |
|
Hello @trevorbox, I am using 0.8.25 installed by OLM on OCP4, so if this is not the latest version I am not sure on how to fix it. But what I report, is that when creating the CR without |
|
I cannot replicate the issue so perhaps you need to update the CRD for that api (it may have changed between upgrades of the operator from olm). Can you compare the CRD on your cluster vs https://github.com/redhat-cop/vault-config-operator/blob/main/config/crd/bases/redhatcop.redhat.io_jwtoidcauthengineconfigs.yaml#L71-L162 . Notice that there is no default. |
|
https://github.com/redhat-cop/vault-config-operator/blob/main/config/crd/bases/redhatcop.redhat.io_jwtoidcauthengineconfigs.yaml#L77 and https://github.com/redhat-cop/vault-config-operator/blob/main/config/crd/bases/redhatcop.redhat.io_jwtoidcauthengineconfigs.yaml#L133 are exactly what I find inside my final object. I realized something, I use ArgoCD to manage the objects, so maybe it reads the CRD, finds these default values and adds them by itself? |
|
Hi @dabelenda, is this still an issue ? Thnx |
|
I still have something weird (using 0.8.27 now). When telling ArgoCD to create the CR without the field Which are the defaults described in the CRD, so probably if the fields are optional they should not contain defaults so that tools like ArgoCD avoid injecting them. Then what happens from there is even more weird, the first reconcile works, everything is "fine", the operator did not try to use But if I edit the CR to modify it (in particular if I remove the field I see inconsistencies that leads to this issue:
|
|
Hi @dabelenda, can you please try a plain Vault + VCO Installation (without ArgoCD) and let us know ? |
|
Testing without ArgoCD is not easy with how the cluster is created and managed. I don't have direct network access to the k8s API. Does it mean that this interaction between ArgoCD and VCO is not a use-case you consider supported? |
|
Hi, |
|
Hi @dabelenda, is this still an issue ? Thank you @raffaelespazzoli I don't see an issue here currently. |
|
Hello @erlisb, Sorry for the delay, I had issues with minikube and not a lot of time to troubleshoot it. I finally managed to get something conclusive: This seems to confirm my initial guess that something puts the default values for the OIDC client authentication. |
|
To continue the investigation: This is the case even without the --server-side option: |
|
@dabelenda sorry, but I still don't get it what issue are you experiencing. Can you elaborate a bit better? Thank you. |
Hello,
As a followup for #165 and the fix #167 there are two (tightly coupled) issues I found.
When creating a CR of Kind JWTOIDCAuthEngineConfig without OIDCCredentials, for example:
The vault-config-operator creates the equivalent configuration in vault, but injects default values in the CR, which results in CR being:
In the new state of the CR, any modification will perform unwanted changes in vault, and when trying to remove the
OIDCCredentialsfield the following errors are written in the vault-config-operator:The text was updated successfully, but these errors were encountered: