reCAPTCHA

Proteggere accesso, registrazione e reimpostazione della password con Google reCAPTCHA in un deployment Kubernetes.

Il servizio web (il modulo login-register) richiede un reCAPTCHA v2 (invisibile) per l’accesso tramite email, l’accesso LDAP, la registrazione e la reimpostazione della password. Crea la chiave e leggi cosa fa ciascuna impostazione in reCAPTCHA; questa pagina spiega come inserirla in Kubernetes.

Servizio	web, in ogni pod di Ayakaleaf Pro; letto all’avvio di web
Pod → Google	RECAPTCHA_ENDPOINT (predefinito https://www.google.com/recaptcha/api/siteverify), a ogni richiesta verificata
Browser → Google	lo script del widget da www.recaptcha.net
Stato	i limiti di frequenza in Redis; la cronologia dei dispositivi “questo browser ha già superato la verifica” in un cookie cifrato
Job periodici	nessuno

​

Configurazione

1. Site key nella ConfigMap

     RECAPTCHA_SITE_KEY: <site key>
     # optional
     # RECAPTCHA_ENDPOINT: https://www.recaptcha.net/recaptcha/api/siteverify
     # CAPTCHA_TRUSTED_USERS: [e-mail]
   

   La site key è pubblica: ogni pagina di accesso la mostra.

2. Secret key e chiave della cronologia dei dispositivi nel Secret

   kubectl -n overleaf patch secret overleaf-secrets --type merge -p '{"stringData":{
     "RECAPTCHA_SECRET_KEY":"<secret key>",
     "DEVICE_HISTORY_SECRET":"'"$(openssl rand -hex 32)"'"}}'
   

   Imposta entrambe le chiavi insieme: con la site key ma senza la secret key, ogni verifica fallisce e nessuno può accedere con una password, registrarsi o reimpostare una password. DEVICE_HISTORY_SECRET deve essere composto da 64 caratteri esadecimali; il container non lo genera.

3. Applica e riavvia

   kubectl apply -f 30-config.yaml
   kubectl -n overleaf rollout restart deployment/overleaf     # or statefulset/overleaf
   

   Quindi verifica che ogni pod raggiunga l’endpoint. I pod rinunciano dopo circa un secondo per ogni tentativo di connessione, e un accesso la cui verifica non può essere eseguita fallisce con un errore:

   for p in $(kubectl -n overleaf get pod -l app=overleaf -o name); do   # app=overleaf-ha for several replicas
     kubectl -n overleaf exec "$p" -- curl -sS -o /dev/null -w "$p %{http_code}\n" \
       https://www.google.com/recaptcha/api/siteverify
   done
   

​

Più repliche

Tutte le repliche devono condividere DEVICE_HISTORY_SECRET, cosa che avviene quando si trova nel Secret. Con valori diversi, un browser che ha superato la verifica su una replica riceverebbe di nuovo il captcha su un’altra. I limiti di frequenza vengono conteggiati in Redis su tutte le repliche.

​

Testato su Kubernetes

Contro un mock dell’endpoint di verifica di Google (considerato attendibile tramite NODE_EXTRA_CA_CERTS da overleaf-certs), su Kubernetes 1.37, i nostri test end-to-end per reCAPTCHA vengono superati (13 casi): su una replica, accesso, registrazione e reimpostazione della password rifiutati ciascuno senza captcha o con un captcha non superato e accettati con uno superato, la cronologia dei dispositivi da DEVICE_HISTORY_SECRET che consente a un browser di saltare il captcha, e CAPTCHA_TRUSTED_USERS; su tre repliche dietro HAProxy, l’accesso LDAP con il captcha.