# =================================================================== # MEMO : Sécurisation d'un service Cloud Run avec IAP (Identity-Aware Proxy) # =================================================================== # # Objectif : Ce document résume les étapes et les permissions nécessaires # pour sécuriser un service Cloud Run avec IAP, en se basant sur # l'expérience acquise avec le service 'internal-launchpad'. # # Date : 2025-11-16 # --- # 1. PRINCIPE FONDAMENTAL ET CONTRAINTE MAJEURE # --- # # L'enseignement le plus important est le suivant : # # > L'activation d'IAP directement sur un service Cloud Run (sans Load Balancer) # > restreint l'accès aux utilisateurs qui font partie de la MÊME organisation # > Google Workspace que le projet Google Cloud. # # Dans notre cas, le projet 'krow-workforce-dev' appartient à l'organisation # 'krowwithus.com'. C'est pourquoi : # - 'admin@krowwithus.com' A PU ACCÉDER au service. # - 'boris@oloodi.com' N'A PAS PU ACCÉDER au service, même avec les bonnes permissions. # # Solution adoptée : Créer des comptes utilisateurs via Google Workspace ou # Cloud Identity (qui est gratuit) dans le domaine 'krowwithus.com' pour # tous les développeurs et administrateurs qui ont besoin d'accéder aux # services internes. # --- # 2. PRÉREQUIS INDISPENSABLES # --- # # Avant de commencer, les éléments suivants doivent être configurés pour le projet : # # a) APIs Google Cloud activées : # - Cloud Run API (`run.googleapis.com`) # - Identity-Aware Proxy API (`iap.googleapis.com`) # - Cloud Build API (`cloudbuild.googleapis.com`) # - Artifact Registry API (`artifactregistry.googleapis.com`) # # Commande pour les activer : # gcloud services enable run.googleapis.com iap.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com --project=krow-workforce-dev # # b) Écran de consentement OAuth configuré : # - IAP utilise OAuth2 pour identifier les utilisateurs. L'écran de consentement est obligatoire. # - URL : https://console.cloud.google.com/apis/credentials/consent?project=krow-workforce-dev # - Type d'utilisateur : "Interne" est préférable si disponible. # - Nom de l'application : Utiliser un nom général (ex: "Krow Workforce Platform"). # # c) Compte de service IAP existant : # - Parfois, ce compte n'est pas créé automatiquement. Il est plus sûr de forcer sa création. # # Commande pour le créer : # gcloud beta services identity create --service=iap.googleapis.com --project=krow-workforce-dev # --- # 3. LOGIQUE DE CONFIGURATION EN 3 ÉTAPES (AUTOMATISÉE DANS LE MAKEFILE) # --- # # Le processus complet pour sécuriser un service se déroule en 3 étapes séquentielles. # # ÉTAPE A : DÉPLOIEMENT SÉCURISÉ DU SERVICE # ----------------------------------------- # Le service doit être déployé en mode privé, puis IAP doit être activé dessus. # # 1. Déployer le service avec l'accès public désactivé : # gcloud run deploy --image --no-allow-unauthenticated ... # # 2. Activer IAP sur le service : # gcloud beta run services update --iap ... # # # ÉTAPE B : AUTORISER IAP À APPELER LE SERVICE # ------------------------------------------- # Une fois IAP activé, le proxy IAP a besoin de la permission d'invoquer (d'appeler) # votre service Cloud Run. Cette permission est accordée au compte de service IAP. # # Commande : # gcloud run services add-iam-policy-binding \ # --member="serviceAccount:service-@gcp-sa-iap.iam.gserviceaccount.com" \ # --role="roles/run.invoker" # # # ÉTAPE C : AUTORISER LES UTILISATEURS À PASSER LE PROXY IAP # ------------------------------------------------------- # C'est ici qu'on ajoute les utilisateurs finaux (qui doivent être dans l'organisation). # Cette commande est spécifique à IAP pour Cloud Run. # # Commande : # gcloud beta iap web add-iam-policy-binding \ # --resource-type=cloud-run \ # --service= \ # --member="user:email@krowwithus.com" \ # --role="roles/iap.httpsResourceAccessor" # --- # 4. AUTOMATISATION VIA LE MAKEFILE # --- # # Tout ce processus est géré par la commande `make deploy-launchpad-full`. # # a) `deploy-launchpad` s'occupe de l'ÉTAPE A. # # b) `configure-iap-launchpad` s'occupe des ÉTAPES B et C. # # - Il lit les utilisateurs depuis `firebase/internal-launchpad/iap-users.txt`. # - Il exécute la commande de l'ÉTAPE B pour le compte de service IAP. # - Il exécute la commande de l'ÉTAPE C pour chaque utilisateur du fichier. # # Pour adapter cela à 'admin-web', il faudra : # 1. Créer des variables similaires à `CR_LAUNCHPAD_...` pour `admin-web`. # 2. Créer de nouvelles cibles `deploy-admin-web-full`, `configure-iap-admin-web`, etc., # en copiant la logique de celles du launchpad et en adaptant les noms de service. # --- # 5. VÉRIFICATION ET DÉPANNAGE # --- # # a) Lister les utilisateurs autorisés : # La commande `make list-iap-users` est le meilleur moyen de vérifier qui a accès. # # b) Erreur "You don't have access" : # - Cause 1 : L'utilisateur n'est pas dans la bonne organisation (le plus probable). # - Cause 2 : L'utilisateur n'est pas dans le fichier `iap-users.txt` et `make configure-iap-launchpad` n'a pas été lancé. # - Cause 3 : Problème de cache de navigateur. Toujours tester dans une nouvelle fenêtre de navigation privée. # - Cause 4 : Délai de propagation des permissions IAM (attendre 2-3 minutes). # # c) Erreur "Forbidden" : # - Cela signifie que l'authentification a réussi mais que la permission d'invoquer le service est manquante. # - La cause la plus probable est que l'ÉTAPE B (donner la permission au compte de service IAP) a échoué ou a été oubliée.