Login Loop nach frischer Installation von Civitas Core 2.0-rc2

CIVITAS / CORE V2 Deployment & Operations
1

Fehlerbeschreibung:

Bei einem Testdeployment von Civitas Core 2.0-rc2 ist es nicht möglich sich am portal-frontend anzumelden. Der Nutzer wird immer wieder zur Login-Seite zurückgeleitet.

Kubernetes:

Die Testinstanz läuft auf einem Nodepool mit einem Node (kubernetes v1.34.2 | 4cores | 16GB) traefik als Ingress Controller und cert-manager.

Environment:

In der testing environment sind gesetzt:

global:
  domain: xxx.xxx.xxxx.de
  instanceSlug: xxx-xxx-xxx
  profile: development
  initialUserEmail: xxxx@xxx.de
  ingress:
    clusterIssuer: 'letsencrypt-prod'
    ingressClass: 'traefik'
  runtimePolicies:
    enabled: true
    failureAction: Audit

Keycloak:

Nach der Installation laufen alle Pods und die Oberfläche von Keycloak ist unter https://idm.<domain> erreichbar. Der Tenant Admin im Realm <instanceSlug> existiert und hat ein Passwort zugewiesen bekommen. Seine Anmeldeversuche werden geloggt und tauchen unter den Events des Nutzers auf Login → Code_to_token → Logout.

Auffälligkeiten:

Der Sessioncookie/token wird in 2 teile gesplittet (Suffixe .0 und .1)

Ist dieses Problem schon jemanden untergekommen oder hat jemand Ideen um das Problem zuverlässiger/genauer einzugrenzen?

Beste Grüße

1 „Gefällt mir“
2

Hi,
Danke für deine Anfrage.
In unseren Testumgebungen ist das Problem noch nicht aufgetaucht. In einer davon läuft auch traefik als ingress. Auf unseren Test Instanzen wird der Session Cookie ebenfalls aufgeteilt. Daran kann es also nicht liegen.
Um das Problem weiter einzuschränken bräuchten wir noch mehr Kontext.

  1. Die Netzwerk Requests im Browser. Vor allem Status Codes !=200, aber mehr Kontext hilft
  2. Stehen in der Browser Console irgendwelche Feher
  3. Gibt es irgendwelche Netzwerk Infrastruktur Besonderheiten? HTTP_PROXY, separate interne Domain etc.
  4. Cluster health. Laufen alle Pods? Gibt es welche die regelmäßig restarten? Ist im Event Log des Clusters was zu sehen?
  5. Lässt sich nachvollziehen, woher das Event Logout im Keycloak kommt? Das scheint mir auffällig, dass ein Logout Event auftaucht. Vielelicht steht dazu was in den Keycloak logs.

Ich hoffe damit können wir den Fehler dann finden.

Viele Grüße
Julian

1 „Gefällt mir“
3

Hallo Julian,

vielen Dank für Deine Antwort. Da ich momentan verschiedene Plattformen teste, bin ich vorerst zu einer anderen gewechselt. Sollte ich Civitas erneut auf dem Cluster installieren und auf die gleichen Probleme treffen, würde ich mich hier wieder melden. Zu Deinen Punkten drei und vier kann ich sagen, dass kein proxy und keine interne domain genutzt wurden. Die Cluster health war auch unauffällig. Alle Pods sind ohne restarts durchgelufen.

Beste Grüße
Christoph

4

Hallo Julian,

ich hatte Zeit Civitas erneut zu deployen und bin tatsächlich auf das selbe Problem gestossen, habe aber diesmal in den Logs den entscheidenden Hinweis gefunden. Es tauchte WARN [org.keycloak.cookie.DefaultCookieProvider] Non-secure context detected; cookies are not secured… auf. Nach einiger Recherche fand ich heraus, dass in IONOS die Pod IP Range unter 100.x.x.x laufen und damit nicht im Bereich der von APISIX vertrauten IP-Adress Bereichen.
Als fix habe ich in den apisix base values components/apisix/values/apisix/base-values.yaml.gotmpl den verwendeten Pod-Cidr Adressbereich unter trustedAddresses: hinzugefügt.
Ich hinterlasse dies hier für den Fall, dass jemand auf das gleiche Problem trifft (laut Internetrecherche setzen einige größere Provider CGNAT ein).

Beste Grüße
Christoph

5

Hallo Christoph,

Danke, für deine Antwort. Das hilft uns sehr. Und wir haben mittlerweile auch von einer weiteren Installation dieses Problem mitgeteilt bekommen. Wir werden schauen, in wie weit wir das Feature einbauen können. Mindestens werden wir die Doku entsprechend anpassen, damit andere die Lösung schneller finden.

Falls es relevnat ist. So wurde es bei der anderen Installation gelöst, damit das Core Repository nicht angepasst werden musste.
Eine Datei apisix-trusted-proxy.yaml.gotmpl neben der global.yaml.gotmpl.

mit dem Inhalt (IP muss entsprechend angepasst werden)

---
apisix:
  apisix:
    rawValues:
      apisix:
        trustedAddresses:
          - 127.0.0.1
          - 10.0.0.0/8
          - 172.16.0.0/12
          - 192.168.0.0/16
          # Added this subnet
          - 100.64.0.0/10

Viele Grüße
Julian

1 „Gefällt mir“