Configuration changes in kratos-external-idp-integrator are not propagated to charms depending on kratos

[arturo-seijas]

Bug Description

Configuration changes in kratos-external-idp-integrator are not propagated to charms depending on kratos if set after the charm is related with oathkeeper. When this happens, oathkeeper doesn't redirect to the IDP but directly requests authentication.

To Reproduce

juju deploy oathkeeper --channel edge
juju deploy identity-platform --channel edge
juju relate oathkeeper self-signed-certificates
juju relate traefik-public self-signed-certificates
juju config traefik-public enable_experimental_forward_auth=True
juju relate oathkeeper traefik-public:experimental-forward-auth
juju relate oathkeeper kratos
juju config kratos dev=True
# Wait for the charms to be idle and config the kratos-external-idp-integrator
juju config kratos-external-idp-integrator client_id=<client_id> client_secret=<client_secret> provider=<provider> issuer_url=<issuer_url> scope="profile email" provider_id=<provider_id>

Environment

Deployed latest/edge IAM bundle. Details are in the script above

Relevant log output

N/A

Additional context

No response

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/IAM-729.

This message was autogenerated

[natalian98]

I was able to reproduce this to some extent, both following the provided steps and without deploying oathkeeper as kratos doesn't depend on it.

After setting juju config kratos-external-idp-integrator client_id=<client_id> client_secret=<client_secret> provider=<provider> issuer_url=<issuer_url> scope="profile email" provider_id=<provider_id>, the changes need ~1m to be reflected in the kratos config file. You can inspect it with:

juju ssh kratos/0 "PYTHONPATH=agents/unit-kratos-0/charm/venv/ python3 -c '
from ops import pebble
p = pebble.Client(\"/charm/containers/kratos/pebble.socket\")
f = p.pull(\"/etc/config/kratos/kratos.yaml\")
print(f.read())
'"

When the identity provider config is provided, kratos-external-idp-integrator triggers a ClientConfigChangedEvent in kratos. On that event, kratos renders a config file with the new IdP, updates the configmap and sets active status.

The issue lies in the fact that there is some latency in mounting the configmap as a volume inside the container, which depends on your kubelet's --sync-frequency config (see more reference here), hence the changes need ~1m (by default) to be propagated. Before that happens, kratos may already set its status to active.

We'll discuss internally if it's worth polling the config file and comparing against the expected value before setting the charm to active.