Dans l'écosystème du développement moderne, la sécurisation des applications repose sur deux fondamentaux : l'authentification (qui est l'utilisateur ?) et l'autorisation (que peut-il faire ?). Si OAuth 2.0 et OpenID Connect se sont imposés comme standards incontournables, leur mise en œuvre concrète soulève souvent de nombreuses questions : quel flux d'autorisation utiliser ? Comment configurer son serveur d'autorisation ? Quelle stratégie adopter selon le type d'application ?

Avec Okta, ces choix techniques deviennent encore plus cruciaux : entre les multiples flux OAuth 2.0/OIDC disponibles et les deux types de serveurs d'autorisation (Org Authorization Server vs Custom Authorization Server), il est essentiel de comprendre les implications de chaque décision pour garantir à la fois la sécurité et la maintenabilité de votre système.

Cet article vous accompagne dans cette réflexion stratégique en clarifiant :

• Les différents flux d'authentification/autorisation et leurs cas d'usage selon votre architecture (application web traditionnelle, SPA, application mobile, API, ou service backend)

• Les critères de choix entre l'Org Authorization Server et un Custom Authorization Server

• Les bonnes pratiques pour implémenter une solution robuste et évolutive

Que vous débutiez avec Okta ou que vous cherchiez à optimiser une intégration existante, ce guide vous donnera les clés pour prendre les bonnes décisions techniques.

Dans le développement moderne d’applications, l’authentification et l’autorisation sont devenues des piliers essentiels de la sécurité. Entre OAuth 2.0, OpenID Connect, et les serveurs d’autorisation d’Okta, il est parfois difficile de savoir quel flux choisir pour son application ou quel serveur utiliser.

Cet article vous guide pas à pas pour comprendre quel flux d’authentification correspond à votre type d’application (Web, SPA, mobile, ou service), et quel serveur d’autorisation (Org ou Custom) répond le mieux à vos besoins.

Avant de détailler OAuth 2.0 et OpenID Connect, faisons un point sur les serveurs d’autorisation (Org et Custom)

Qu’est‑ce qu’un serveur d’autorisation (vue fonctionnelle)

Un serveur d’autorisation est le composant qui contrôle l’accès à des ressources protégées dans un domaine de sécurité. Dans OAuth 2.0 / OIDC, il reçoit des demandes de la part d’applications clientes, authentifie l’utilisateur ou le client, recueille le consentement, applique des politiques d’accès (scopes, audiences, groupes, conditions), puis émet des jetons signés (Access Token, ID Token, et éventuellement Refresh Token). Chaque serveur est identifié par un issuer (URI) et publie sa clé publique pour que les API puissent vérifier les jetons.

Entrées → Traitements → Sorties

• Entrées : paramètres de la demande (client_id, redirect_uri, scope, code_challenge PKCE…), identifiants/preuves d’authentification (utilisateur ou client), consentement.

• Traitements : authentification, évaluation des policies, génération et signature des jetons, journalisation.

• Sorties : redirection avec authorization code (selon le flow), Access Token, ID Token, Refresh Token ou erreurs normalisées.

Les endpoints standard d’un serveur d’autorisation Okta

Chaque serveur (Org ou Custom) expose des URLs bien définies. Voici les plus importantes :

• Discover

  • https://yourOktaDomain.com/.well-known/openid-configuration → Retourne toute la configuration OIDC (endpoints, scopes supportés, clés, etc.).

  • https://yourOktaDomain.com/.well-known/oauth-authorization-server → Version OAuth 2.0 pure (moins courante).

• Autorisation

  • https://yourOktaDomain.com/oauth2/{auth_server_id}/v1/authorize → Démarre le flux : affiche la page de login, gère le consentement, redirige avec un code.

• Émission de jetons

  • https://yourOktaDomain.com/oauth2/{auth_server_id}/v1/token → Échange un code contre des tokens (Authorization Code + PKCE), ou délivre un token via client_credentials.

• Vérification et informations

  • /v1/keys → Clés publiques (JWKS) pour vérifier la signature des tokens.

  • /v1/userinfo → Retourne les données de l’utilisateur (email, nom, etc.) avec un Access Token valide.

  • /v1/introspect → Vérifie si un token est actif, expiré ou révoqué (uniquement sur Custom Server).

  • /v1/revoke → Révoque un token immédiatement (logout forcé, sécurité).

Note : Remplace {auth_server_id} par default (Custom Server par défaut) ou ton ID personnalisé. Pour l’Org Authorization Server, les chemins sont en /oauth2/v1/... sans auth_server_id.

Comprendre les fondamentaux : OAuth 2.0 et OpenID Connect

Okta prend en charge plusieurs protocoles d'authentification et d'autorisation : SAML 2.0, Secure Web Authentication (SWA), ainsi que les standards modernes OAuth 2.0 et OpenID Connect (OIDC). Ces deux derniers se sont imposés comme les piliers des intégrations d'applications web, mobiles et API.

Alors que SAML et SWA répondent encore à des cas d'usage legacy, OAuth 2.0 et OIDC offrent une approche plus flexible et standardisée. Mais avant de plonger dans leurs subtilités, posons-nous les bonnes questions : avez-vous besoin de savoir qui se connecte (identité), à quoi il peut accéder (autorisations), ou s'agit-il d'un service qui appelle un autre service sans utilisateur humain ? Ces distinctions orientent directement vos choix d'architecture.

OAuth 2.0 vs OpenID Connect : deux protocoles complémentaires

• OAuth 2.0 contrôle et délègue l'autorisation d'accès à une ressource protégée. Il assure la sécurité des APIs via des Access Tokens à portée limitée (scopes), sans exposer les identifiants utilisateur.

• OIDC étend OAuth 2.0 en ajoutant l'authentification et le Single Sign-On (SSO). Il fournit un ID Token (JWT signé) contenant l'identité vérifiée de l'utilisateur : nom, email, rôle, photo de profil.

En pratique avec Okta La majorité des applications nécessitent les deux protocoles. Lors d'un flux complet, Okta délivre à la fois un ID Token (identité) et un Access Token (autorisation). Okta propose des modèles de déploiement qui abstraient ces protocoles, vous n'avez donc pas à les manipuler directement.

Comprendre cette complémentarité vous permet de choisir le bon flux et d'éviter les erreurs courantes : utiliser un Access Token pour l'identité, exposer un ID Token à une API tierce, ou mal dimensionner la durée de vie des tokens

Choisir le flux OAuth 2.0 / OpenID Connect adapté à votre type d’application

Lors de la création d’une nouvelle intégration d’application dans Okta, comme illustré dans la capture ci-dessous, vous êtes invité à choisir une méthode de connexion (Sign-in method) et un type d’application (Application type).

Ces deux choix déterminent directement le flux d’authentification OAuth 2.0 / OIDC que votre application utilisera.

Okta propose plusieurs méthodes d’intégration, chacune adaptée à un cas d’usage particulier.

• SAML 2.0 : un standard basé sur XML, principalement utilisé dans les environnements d’entreprise pour le Single Sign-On (SSO). Il reste adapté aux applications existantes qui ne prennent pas en charge OAuth 2.0 ou OIDC.

• SWA (Secure Web Authentication) : une méthode propre à Okta, utile lorsque l’application ne supporte ni SAML ni OIDC. Elle repose sur une authentification simulée via un formulaire web.

• API Services : utilisée pour les intégrations sans utilisateur (machine-to-machine), basée sur le flux Client Credentials d’OAuth 2.0.

Cependant, pour la plupart des applications modernes – web, mobiles ou orientées API – le choix recommandé est OIDC – OpenID Connect, qui s’appuie sur la puissance et la flexibilité du protocole OAuth 2.0.

1. La section Sign-in method permet de sélectionner le protocole d’authentification :

   • OIDC – OpenID Connect (recommandé pour les applications modernes basées sur OAuth 2.0),

   • SAML 2.0,

   • SWA (Secure Web Authentication),

   • ou API Services pour les échanges machine-to-machine.

2. La section Application type définit l’environnement et le flux approprié :

   • Web Application → flux Authorization Code ( + PKCE : Optionnel mais fortement recommandé )

   • Single-Page Application → flux Authorization Code with PKCE,

   • Native Application → flux Authorization Code with PKCE,

   • API Services → flux Client Credentials.

En combinant ces deux paramètres, Okta détermine automatiquement le flux OAuth 2.0 ou OIDC le plus adapté à votre architecture — qu’il s’agisse d’une application web, d’un front-end SPA, d’une app mobile ou d’un service backend.

OIDC : le standard moderne pour l’authentification et l’autorisation

OpenID Connect (OIDC) étend le protocole OAuth 2.0 en ajoutant une couche d’authentification.

Alors qu’OAuth 2.0 se concentre sur le contrôle d’accès aux ressources (autorisation), OIDC permet d’identifier l’utilisateur de manière sécurisée.

• Authorization Code Flow :

Le Authorization Code Flow (ou Code Flow) est défini par la spécification OAuth 2.0 (RFC 6749, section 4.1). C'est le flux le plus couramment utilisé pour les applications web côté serveur et constitue la base des intégrations OAuth/OIDC modernes.

Ce flux est conçu pour offrir un haut niveau de sécurité en séparant l'authentification de l'utilisateur (qui se déroule dans le navigateur) de l'échange de tokens (qui se produit de manière sécurisée entre serveurs backend). Les tokens d'accès ne transitent jamais directement dans le navigateur, réduisant ainsi les risques d'exposition.

Étapes du flux Authorization Code

1. Ton application demande un code d’autorisation Elle redirige l’utilisateur vers Okta (/authorize).

2. Okta affiche la page de connexion L’utilisateur voit le login Okta dans son navigateur.

3. L’utilisateur se connecte et donne son accord Il entre ses identifiants, accepte les permissions demandées.

4. Okta renvoie un code d’autorisation au navigateur Le code arrive dans l’URL de redirection (ex: ?code=abc123).

5. Ton application envoie le code + le client secret à Okta Appel backend vers /token (pas dans le navigateur !).

6. Okta répond avec les tokens Tu reçois :

   • access_token (pour appeler l’API)

   • id_token (identité de l’utilisateur)

   • refresh_token (optionnel, pour renouveler)

7. Ton application appelle l’API avec l’access_token En-tête : Authorization: Bearer <token>

8. L’API vérifie le token avant de répondre Elle utilise les clés publiques d’Okta (/keys) pour valider la signature.

💡

Recommandation: Franchement, mettez PKCE partout — SPA, mobile, ou même backend

En fait, depuis 2023, il est fortement recommandé d’utiliser le flux “Authorization Code Flow with PKCE”, y compris pour les applications web côté serveur.

Cette approche, initialement conçue pour les applications mobiles et SPA, ajoute une couche de sécurité supplémentaire au flux classique en protégeant l’échange du code d’autorisation.

Nous reviendrons plus loin sur le fonctionnement détaillé du PKCE (Proof Key for Code Exchange) et sur les raisons de son adoption généralisée.

Référence : Okta Developer Docs – Authorization Code Flow with PKCE

• Authorization Code Flow with PKCE : la version renforcée du Code Flow

Le Authorization Code Flow with PKCE (Proof Key for Code Exchange) est une évolution du flux d’autorisation classique décrite dans la RFC 7636.

À l’origine, ce mécanisme a été conçu pour les applications mobiles et Single Page Applications (SPA), où le client_secret ne peut pas être protégé.

Il est aujourd’hui recommandé pour toutes les applications, y compris celles côté serveur, car il renforce la sécurité du processus d’échange de tokens.

Principe de fonctionnement

Le fonctionnement reste globalement identique au Code Flow classique, à une différence majeure :

l’application génère une clé temporaire unique, appelée code_verifier, qu’elle transforme en un code challenge (haché).

Cette clé permet au serveur d’autorisation (Okta) de vérifier que le code d’autorisation échangé n’a pas été intercepté ou modifié pendant le processus.

Étapes du flux Authorization Code avec PKCE

1. Génération de la clé PKCE
   L’application commence par générer un code verifier (clé aléatoire) et en déduit un code challenge (sa version hachée). Ces deux éléments serviront à prouver l’identité de l’application lors de l’échange du code d’autorisation.

2. Demande d’un code d’autorisation
   L’application redirige l’utilisateur vers le serveur d’autorisation Okta (/authorize), en incluant le code_challenge.

3. Affichage de la page de connexion
   Okta affiche la page de connexion à l’utilisateur. Celui-ci choisit une méthode d’authentification (identifiant/mot de passe, SSO, etc.).

4. Authentification et consentement
   L’utilisateur s’identifie et, si nécessaire, accepte les autorisations demandées par l’application (scopes).

5. Redirection vers l’application
   Une fois authentifié, Okta redirige le navigateur vers l’application avec un code d’autorisation temporaire.

6. Échange du code d’autorisation contre des tokens
   L’application envoie ce code à Okta, accompagné du code_verifier, pour prouver qu’elle est bien à l’origine de la demande.

7. Validation du code PKCE
   Okta compare le code_verifier reçu avec le code_challenge initial afin de vérifier l’intégrité de la requête.

8. Remise des tokens
   Si tout est correct, Okta renvoie un Access Token, un ID Token, et éventuellement un Refresh Token.

9. Accès aux ressources protégées
   L’application utilise l’Access Token pour interroger une API (le Resource Server) au nom de l’utilisateur.

10. Réponse du serveur de ressources
    L’API valide le token et renvoie les données demandées.

Exemple de code : Authorization code flow + PKCE

// On commence par générer deux valeurs aléatoires et uniques pour chaque connexion :
// 1. code_verifier : une chaîne longue et imprévisible (minimum 43 caractères)
//    Elle sert à prouver que c'est bien notre application qui a initié la demande.
//    On la garde en mémoire (session ou stockage local) pour la réutiliser plus tard.
const { generators } = require('openid-client');
const code_verifier = generators.codeVerifier();

// 2. state : une autre valeur aléatoire, différente à chaque fois.
//    Elle empêche les attaques CSRF : si quelqu'un essaie de forcer une redirection,
//    cette valeur ne correspondra pas à celle qu'on a envoyée.
const state = require('crypto').randomBytes(32).toString('hex');

// On calcule le code_challenge à partir du code_verifier (hash en SHA256)
const code_challenge = generators.codeChallenge(code_verifier);

// On construit l'URL complète pour rediriger l'utilisateur vers Okta
const authUrl = `https://my-domaine.okta.com/oauth2/default/v1/authorize?` +
  `client_id=0oaxxx` +
  `&response_type=code` +
  `&scope=openid profile email` +
  `&redirect_uri=http://localhost:3000/callback` +
  `&state=${state}` +              // Valeur aléatoire, vérifiée au retour
  `&code_challenge=${code_challenge}` +  // Preuve que le code vient bien de nous
  `&code_challenge_method=S256`;

// On supprime les espaces et retours à la ligne pour une URL propre
const cleanUrl = authUrl.replace(/\s/g, '');

// On stocke les deux valeurs secrètes avant de rediriger
req.session.code_verifier = code_verifier;
req.session.state = state;

res.redirect(cleanUrl); // L'utilisateur est envoyé vers la page de login Okta

Client Credentials Flow : le flux pour les communications machine-to-machine

Le Client Credentials Flow est conçu pour les applications sans utilisateur final — autrement dit, pour les scénarios où une application ou un service doit accéder à une ressource protégée au nom d’elle-même.

Ce flux est typique dans les architectures de microservices ou pour les automatisations backend, où un service doit appeler une API sécurisée.

Principe général

Contrairement aux autres flux OAuth 2.0, celui-ci ne passe pas par une interaction utilisateur.

L’application cliente s’authentifie directement auprès du serveur d’autorisation à l’aide de ses propres identifiants (généralement un Client ID et un Client Secret), et obtient en retour un Access Token.

Ce jeton permet ensuite d’appeler les API protégées.

Étapes du flux Client Credentials Flow

• Requête de jeton d’accès
  L’application envoie une requête au serveur d’autorisation Okta vers le point de terminaison /token, en s’authentifiant à l’aide de ses propres identifiants (client_id et client_secret).
  Ces identifiants sont configurés lors de la création de l’intégration d’application (type API Services).

• Réponse avec le jeton d’accès
  Si les informations d’identification sont valides, Okta renvoie un Access Token signé, limité dans le temps et contenant les scopes autorisés.

• Appel de l’API avec le jeton
  L’application utilise ce jeton d’accès pour appeler le Resource Server (votre API sécurisée). Le jeton prouve que la requête vient d’une application autorisée.

• Validation et réponse
  Le serveur de ressources vérifie la validité du jeton auprès d’Okta avant de fournir les données ou d’exécuter l’action demandée.

💡

Points clés à retenir

• Ce flux ne fournit pas d’ID Token, car aucun utilisateur n’est impliqué.

• Les scopes doivent être définis avec précision afin de limiter les permissions du client.

• Les identifiants (client_id et client_secret) doivent être stockés de manière sécurisée (jamais dans le code source).

• En pratique, ce flux est presque toujours utilisé avec un Custom Authorization Server, car il permet de créer des tokens sur mesure pour vos propres APIs.

Exemple de code : Client Credentials Flow (M2M)

const getApiToken = async () => {
  // Prépare la requête sans utilisateur
  const params = new URLSearchParams({
    grant_type: 'client_credentials',
    scope: 'api:read api:write' // -> Scopes définis dans le Custom Server
  });

  // Authentifie le service avec client_id + secret, ici on pointe sur le custom serveur
  const response = await fetch('https://my-domain.okta.com/oauth2/default/v1/token', {
    method: 'POST',
    headers: {
      'Authorization': 'Basic ' + Buffer.from('0oayyy:secret').toString('base64'),
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: params
  });

  const { access_token } = await response.json();
  return access_token; // -> Token pour appeler ton API
};

// Exemple d'appel API
const token = await getApiToken();
fetch('https://api.monservice.com/data', {
  headers: { Authorization: `Bearer ${token}` }
});

Les flux OAuth 2.0 dépréciés : Implicit et ROPG

Bien que toujours définis dans la spécification OAuth 2.0 (RFC 6749), certains flux historiques sont aujourd’hui considérés comme obsolètes ou à usage restreint.

C’est notamment le cas de l’Implicit Flow et du Resource Owner Password Credentials Flow (ROPG).

L’Implicit Flow, conçu à l’origine pour les applications Single-Page (SPA) dépourvues de capacités sécurisées côté serveur, permettait de récupérer un jeton d’accès directement via l’URL après redirection.

Mais cette approche présente plusieurs failles : exposition du jeton dans le navigateur, impossibilité de vérifier sa signature, et risques de vol via des scripts tiers.

C’est pourquoi Okta, comme l’ensemble de l’écosystème OAuth, recommande désormais de le remplacer par le Authorization Code avec PKCE plus sûr et universel.

Le Resource Owner Password Flow (ROPG), lui, autorise une application à collecter directement les identifiants de l’utilisateur (nom d’utilisateur et mot de passe) pour obtenir un jeton d’accès.

Ce flux contourne toutefois la page d’authentification Okta et empêche l’application de bénéficier de mécanismes avancés tels que la MFA, la détection d’anomalies ou l’authentification adaptative.

Okta précise dans sa documentation officielle que ce flux ne doit être utilisé que dans les environnements de confiance ou à des fins de compatibilité technique :

“If your app is high-trust and you own both the client and the resource it accesses, you can use the Resource Owner Password flow. However, this flow is not compatible with multifactor authentication, and should be replaced by the Authorization Code or Interaction Code flow whenever possible.”

(Source : Okta Developer Docs – OAuth & OpenID Connect Concepts)

💡

Recommandation actuelle

Depuis 2023, les bonnes pratiques de sécurité (Okta, IETF, Auth0) convergent :

Utilisez le Code Flow with PKCE pour toutes les applications avec utilisateur, et le Client Credentials Flow pour les échanges entre services.

Conclusion

On arrive au bout de ce guide, et l’essentiel tient en une idée : choisir le bon flux OAuth/OIDC et le bon serveur Okta, c’est protéger ton application sans te prendre la tête.

• Si tu as des utilisateurs (web, SPA, mobile) → Authorization Code avec PKCE, point final. C’est le standard depuis 2023, ça marche partout, ça supporte la MFA, et les SDK Okta le font tout seul.

• Si c’est du machine-to-machine → Client Credentials + Custom Authorization Server. C’est là que tu définis tes propres audiences, scopes, claims. Tes APIs deviennent vraiment à toi.

• Oublie l’Implicit et le ROPG. Sauf si t’as une vieille app qui traîne dans un coin… et même là, planifie la migration.

Org vs Custom : le match en 3 lignes

Mon conseil de dev à dev : Commence avec l’Org Server — c’est prêt en 2 clics. Dès que tu a besoin d’un scope custom, une audience propre ou un claim métier → passe au Custom.

Défi actuel

Chaque application moderne doit gérer l’authentification et l’autorisation des utilisateurs.
Construire ces mécanismes en interne paraît simple au départ, mais devient rapidement un casse-tête technique et sécuritaire :

• hachage et stockage sécurisé des mots de passe

• gestion des sessions et des tokens (Access / Refresh)

• mise en place du MFA (Multi-Factor Authentication) ou encore du SSO (SIngle sign On)

• intégration avec des réseaux sociaux ou des annuaires d’entreprise,

• conformité avec les réglementations (RGPD, CCPA, HIPAA),

• protection contre les attaques (brute force, bots, injections).

Autant de sujets complexes, qui consomment un temps précieux et détournent les équipes de leur objectif principal : créer de la valeur pour l’utilisateur.

Qu’est ce qu’Auth0

Auth0 est une plateforme d’Identity-as-a-Service (IDaaS) qui permet aux entreprises de gérer facilement l’authentification et l’autorisation de leurs applications. Concrètement, c’est un service qui prend en charge tout ce qui concerne la gestion de l’identité des utilisateurs : connexion, inscription, fédération avec des fournisseurs externes, sécurisation des accès et contrôle granulaire des permissions.

Au lieu de développer et maintenir en interne ces mécanismes complexes, Auth0 fournit un ensemble d’outils prêts à l’emploi, extensibles et conformes aux standards du marché (OAuth2, OpenID Connect, SAML, etc.). Les équipes peuvent ainsi se concentrer sur leur cœur de métier, tout en bénéficiant d’une infrastructure de sécurité éprouvée et constamment mise à jour.

Auth0 s’adresse aussi bien aux applications B2C (grand public), B2B (clients professionnels) qu’aux usages internes (applications métiers). Sa force réside dans sa modularité : vous activez uniquement les fonctionnalités dont vous avez besoin, et vous les faites évoluer au rythme de vos projets.

La promesse d’Auth0

« Centralisez et gérez vos utilisateurs, qu’ils viennent de multiples fournisseurs d’identité, et offrez-leur une expérience de connexion fluide, moderne et à l’image de votre marque.
Grâce à un haut niveau de personnalisation, contrôlez l’accès avec précision et répondez même aux exigences de sécurité les plus complexes»
(Auth0 Docs)

La solution Auth0

Quand on parle d’authentification et d’autorisation, chaque équipe technique se heurte aux mêmes difficultés : sécuriser les mots de passe, gérer les sessions et tokens, mettre en place du MFA, intégrer différents fournisseurs d’identité, respecter des normes de conformité et se protéger contre les attaques. Mais il faut aussi aller plus loin : définir qui a accès à quoi, dans quelles conditions et pour combien de temps. Cette granularité est essentielle pour concilier productivité et sécurité.

Auth0 s’impose ici comme une plateforme qui prend en charge ces problématiques de bout en bout, grâce à un ensemble de modules spécialisés et interconnectés. Elle ne se limite pas à vérifier l’identité d’un utilisateur : elle permet aussi de contrôler finement ses droits d’accès, de contextualiser les règles (selon l’appareil, l’heure, la localisation) et d’ajuster la durée de validité des permissions

1. Sécuriser les identifiants sans compromis

Stocker et protéger les mots de passe n’est jamais anodin. Auth0 applique par défaut les meilleures pratiques de hachage et de stockage sécurisé, en s’appuyant sur des algorithmes éprouvés (bcrypt, argon2, etc.). Cela permet aux équipes de ne pas réinventer ces mécanismes sensibles et d’éviter les erreurs qui exposeraient les utilisateurs. Comme le rappellent les docs Auth0, déléguer cette responsabilité réduit considérablement le risque lié à une mauvaise implémentation maison.

2. Gérer efficacement les sessions et tokens

Les applications modernes s’appuient sur OAuth2 et OpenID Connect pour sécuriser l’accès. Auth0 gère nativement le cycle de vie des Access Tokens et Refresh Tokens, ce qui garantit une authentification fluide tout en limitant la surface d’attaque. Grâce à des règles de rotation et d’expiration configurables, il est possible d’ajuster la sécurité sans sacrifier l’expérience utilisateur.

3. Offrir MFA et SSO simplement

La mise en place du Multi-Factor Authentication (MFA) et du Single Sign-On (SSO) est souvent un chantier complexe. Auth0 propose des modules prêts à l’emploi : un clic pour activer le MFA (via SMS, email, TOTP ou push notification) et des connecteurs standardisés pour le SSO. Résultat : vos utilisateurs bénéficient d’une expérience fluide, avec une couche de sécurité renforcée qui reste simple à activer.

4. Intégrer plusieurs fournisseurs d’identité

Un des grands atouts d’Auth0 est la capacité à fédérer plusieurs sources d’identité : authentification sociale (Google, Facebook, Apple), annuaires d’entreprise (Active Directory, LDAP), protocoles standards (SAML, OpenID Connect). Les équipes n’ont plus besoin de coder ces intégrations à la main : il suffit de configurer le provider dans le dashboard Auth0. Cette flexibilité permet de répondre aux besoins B2C, B2B et internes, sans multiplier les implémentations.

5. Respecter la conformité réglementaire

RGPD, CCPA, HIPAA : autant de sigles qui représentent des obligations fortes en matière de protection des données. Auth0 intègre des fonctionnalités de gestion de consentement, de journalisation et de contrôle granulaire des données utilisateurs. Cela facilite la conformité tout en gardant la main sur la gouvernance des identités. Les équipes gagnent du temps et limitent leur exposition légale, tout en offrant de la transparence aux utilisateurs finaux.

6. Protéger contre les menaces avancées

Au-delà de l’authentification de base, Auth0 inclut des protections intelligentes contre les attaques les plus fréquentes : brute force, credential stuffing, bots, injections. Grâce à la détection d’anomalies, la plateforme peut bloquer ou défier une tentative suspecte en temps réel. Cela permet de renforcer la sécurité sans alourdir inutilement l’expérience des utilisateurs légitimes.

7. Contrôler finement l’accès aux ressources

Auth0 ne se limite pas à identifier un utilisateur : la plateforme permet de gérer ses autorisations via RBAC (Role-Based Access Control) ou ABAC (Attribute-Based Access Control). Cela permet de définir précisément qui a accès à quoi, dans quelles conditions (localisation, appareil, heure) et pour combien de temps.

8. Offrir une expérience cohérente et personnalisée

Avec Universal Login, Auth0 permet de proposer un écran de connexion fluide et entièrement personnalisable à votre charte graphique. L’utilisateur reste immergé dans votre univers, qu’il choisisse de se connecter avec un email, un réseau social ou un SSO d’entreprise. Résultat : une expérience moderne et sans rupture, qui renforce la confiance et l’adoption.

9. Personnaliser et étendre facilement

Chaque organisation a des besoins spécifiques en matière de gestion d’identité. Grâce aux Rules et Actions, Auth0 rend le processus d’authentification extensible : vous pouvez enrichir un token avec des données externes, appliquer des politiques dynamiques en fonction du contexte, ou encore déclencher des appels vers vos propres APIs au moment de la connexion. Cette flexibilité permet d’aligner la sécurité et l’expérience utilisateur avec vos exigences métiers les plus pointues.

Conclusion

La gestion de l’identité n’est plus un simple détail technique : c’est un pilier de la sécurité, de la conformité et de l’expérience utilisateur. Construire en interne des mécanismes d’authentification et d’autorisation robustes prend du temps, multiplie les risques et détourne les équipes de leur véritable mission.

Avec Auth0, vous disposez d’une plateforme complète, modulaire et extensible qui prend en charge ces problématiques de bout en bout : de la protection des identifiants jusqu’à la gestion fine des accès, en passant par la conformité, la personnalisation et la détection des menaces.

En adoptant Auth0, vous gagnez en rapidité de mise en œuvre, en tranquillité d’esprit et en capacité à offrir une expérience fluide à vos utilisateurs. Bref, vous transformez un casse-tête technique en un véritable levier de confiance et de croissance.

Malgré l’adoption quasi-généralisée de modèles de sécurité « Principe du moindre privilège » et/ou « ZeroTrust », plus de 60% des cyberattaques en 2024 étaient encore liées à des usurpations d’identité et/ou à des droits d’accès excessifs. Les solutions IDP (IDentity Provider), telles Okta ou EntraID, ont vocation à réduire considérablement ce type de risques par la mise en place de politiques d’authentification et d’accès centralisées et sécurisées (SSO, MFA contextuel, gouvernance des identités…).

En théorie, avec ce type de solutions, on peut dormir tranquille, surtout si l’on utilise des facteurs dits « phishing résistants » ...Sauf que, ce n’est pas nécessairement aussi simple !

Si le fait de mettre en place un IDP moderne réduit considérablement la surface d’attaque, il reste encore quelques angles morts ! En effet, les IDP modernes sont très efficaces pour gérer l’authentification, les politiques de droits d’accès ou encore le cycle de vie des identités, mais jusqu’à présent, ils répondaient de manière encore trop imparfaite à deux enjeux importants :

• La gestion de la posture de sécurité des identités

• La détection et la réponse aux menaces liées aux tentatives d’accès

Fort de ce constat, Okta a récemment lancé 2 nouveaux modules intégrés à sa solution Okta Identity Platform, qui apportent des réponses très concrètes : ISPM et ITDR.

L’objet de cet article est de mieux comprendre à quoi servent les modules ISPM (Identity Security Posture Management) et ITDR (Identity Threat Detection & Response).

I. Gestion de la Posture de Sécurité des Identités (ISPM)

Commençons par une définition claire : l'ISPM sert à identifier et corriger, en amont de toute tentative d’accès, les vulnérabilités potentielles sur les identités.

Comme sa définition l’indique, son rôle est donc proactif (en amont). On n’attend pas que quelqu’un essaie de se connecter pour identifier et corriger les vulnérabilités potentielles.

Donnons quelques exemples de vulnérabilités sur les identités :

• Attribution excessive de droits/privilèges

• Mots de passe faibles ou inchangés

• Incohérence dans les parcours d’authentification (notamment les conditions de déclenchement du MFA ou encore les facteurs MFA eux-mêmes)

• Utilisation incorrecte des comptes de service (utilisation des comptes de service comme comptes humains et réciproquement)

• Gestion incomplète du cycle de vie des identités (par exemple, lors d’une suppression de compte, Okta est mis à jour mais pas l’AD ou réciproquement)

• Utilisation de comptes partagés

Ces exemples permettent de bien comprendre le rôle du module ISPM d’Okta : offrir une vue centralisée et complète de toutes les vulnérabilités potentielles à travers l’ensemble de l’écosystème lié à l’identité, afin de les corriger en amont, avant toute tentative d’authentification par un utilisateur !

Un de nos clients a résumé l’intérêt d’ISPM de la façon suivante, et je trouve sa formulation assez juste : « c’est un peu comme une sentinelle qui vérifierait en continue si l’on a bien fait les choses dans notre gestion des identités, et si ce n’est pas le cas, il nous invite à les corriger ».

II. Détection et Réponse aux Menaces sur les Identités (ITDR)

Définition : l'ITDR d'Okta se concentre sur la surveillance continue et la réponse aux menaces ciblant les identités.

En première lecture, cela ressemble à ce que fait l’ISPM, à l’exception près qu’il s’agît d’opérations réalisées après l’authentification. Il n’est plus question de qualifier et améliorer la posture de sécurité des identités mais de réagir et remédier en temps réel à une possible compromission.

Exemples concrets :

• Si un attaquant tente d’accéder aux comptes d’utilisateurs par force brute (il essaie des milliers de paires de login/password différents), l’adresse IP de cet attaquant sera immédiatement bloquée.

• Une fuite de données sur le darkweb révèle les identifiants et mots de passe d’utilisateurs. Les comptes seront alors mis en quarantaine (« suspendus ») en attendant que les utilisateurs concernés réinitialisent leur mot de passe via une procédure sécurisée n’utilisant pas leurs credentials actuels

• Détection d’un comportement anormal : un utilisateur se connecte depuis un lieu et à une heure très inhabituels. ITDR va alors identifier une activité suspecte et un deuxième facteur (par exemple) sera déclenché

• Détection et réaction automatique aux attaques de Phishing (Hameçonnage). Si un employé clique par mégarde sur un lien malveillant et fournit ses identifiants, ITDR va alors identifier qu’un utilisateur utilisant les mêmes credentials essaie de se connecter depuis un lieux différent ou encore une machine différente. La réponse configurable d’ITDR peut alors être : autre facteur d’authentification requis (car finalement un utilisateur légitime peut aussi prendre l’avion et utiliser un autre ordinateur) ou encore impossibilité de se connecter depuis un autre terminal.

• Universal Logout : Mécanisme qui permet de fermer toutes les sessions actives de l’utilisateur. Pas uniquement la session Okta, mais aussi (et peut-être surtout) les sessions des applications et services fédérés par Okta. Ainsi, si un attaquant récupère un token de session Okta (stocké sous forme d’un cookie sécurisé) et essaie de le jouer depuis un autre poste, ITDR le détectera et déclenchera l’universal logout sur toutes les sessions Okta actives et sur l’ensemble des sessions des applications fédérées.

Les exemples donnés visent à mieux comprendre les finalités respectives d’ISPM et ITDR, le premier permettant une surveillance continue du respect des bonnes pratiques de sécurité des identités en amont (la posture), le deuxième étant une surveillance et une réponse en continue aux tentatives réelles d’authentification.

Ci-après un schéma récapitulatif simplifié:

CONCLUSION

Avec l'adoption croissante des environnements multiclouds et SaaS, les équipes de sécurité rencontrent des défis pour maintenir la visibilité et le contrôle sur leur paysage d'identités. Les solutions ISPM et ITDR ont pour objet d’une part de diminuer la surface d'attaque en détectant les vulnérabilités potentielles liées aux identités, et d’autre part détecter les menaces effectives pour une remédiation rapide. En combinant ces deux approches, les organisations peuvent renforcer leur posture de sécurité globale et se protéger plus efficacement encore contre les menaces basées sur les identités.

De manière plus générale, Okta prenant une place de plus en plus centrale dans le SI de nombreuses organisations, l’idée d’aider ses clients à Monitorer, Surveiller, Piloter leurs identités et plus généralement réduire toute exposition au risque d’accès frauduleux est clairement une direction attendue par le marché.

Il y avait déjà « Okta ThreatInsight », et dorénavant, les clients d’Okta disposent de deux armes supplémentaires : ISPM et ITDR.

Pour ceux d'entre nous qui entendent de plus en plus les termes Transformation Digitale, API, DevOps, Cloud Native, CI/CD, Repo, Containers, Kuberteness, SAST, SCA, DAST, CNAPP, ZeroTrust, CNCF, j'en passe et des meilleurs, et qui ne comprennent pas toujours de quoi on parle, cet article a pour objectif de démythifier un peu tous ces termes jargoneux pour essayer de comprendre - de façon non technique - les raisons d'un tel engouement.
Nous commencerons par un peu d'histoire, pour mieux comprendre notre présent et essayer d'anticiper l'avenir, sans pour autant devenir nous-mêmes des informaticiens.

Introduction

Quand on se promène dans les couloirs d'une entreprise (même pas besoin d'être en présence de développeurs), ou qu'on participe à une visioconférence en ligne, on entend souvent les phrases un peu absonces du genre: "C'est prévu dans notre plan de transformation digitale", "DevOps, c'est fait pour les entreprises Cloud Native et Agiles", ou encore "You Build it, You Run it", voire même "il faut qu'on Shifte Left notre approche".

On constate par ailleurs que toute personne en lien de près ou de loin avec l'informatique est devenue un XXXX_OPS (devops engineer, secops leader, devsecops architect, etctera....). Même les gens du marketing s'y mettent. Si vous ne me croyez pas, consultez les profils sur Linkedin, de moins en moins de Digital Marketing Specialists et de plus en plus de MarketingOps Specialists! Incroyable!

Que s'est-il donc passé? Et en quoi ça change la donne?

Le cloud comme génèse

Il y a une vingtaine d'années (+ ou -), le Cloud a débarqué dans nos vies privées et professionnelles. Aujourd'hui, tout est dans le Cloud! Même un bon vieux Datacenter d'une banque avec ses bons vieux Mainframes est devenu un Cloud Privé! On est même actuellement à l'ère du MultiClouds hybride (la classe)!

Grâce à la virtualisation (et 2 ou 3 autres trucs), on a pu allouer des ressources informatiques à des développeurs (au début de la CPU/RAM/Stockage/Network) en quelques cliques seulement. Et ça franchement, c'était vraiment cool car jusqu'alors les développeurs devaient faire une demande au service informatique et au bout de plusieurs semaines (dans le meilleur des cas) on leur disait "le serveur (physique) est livré"... ce n'était pas fini pour autant car il fallait encore passer pas mal d'heures à configurer cette machine, la connecter au réseau, et donner les bons droits d'accès!

Autrement dit, d'un seul coup, les développeurs ont eu accès à de la ressource informatique d'infrastructure en quelques secondes, et ils/elles pouvaient la reconfigurer en quelques secondes également. Pour un développeur, c'était un pas de géant!

Mais jusque-là, cette petite révolution ne concernait que les services informatiques encore divisés en 4 grands pôles bien silotés qu'on appelait "Developpement, Test, Intégration, Production", et les projets informatiques continuaient de suivre des cycles infernaux dits de "Waterfall" ou "cycle en V", avec ces 8 phases incontourbables:

1- on décrit notre besoin
2- on spécifie fonctionnellement la solution
3- on en fait des spécifications techniques adossées à un joli schéma d'architecture voire d'urbanisme
4- on code/développe
5- on teste techniquement et fonctionnellement
6- on prend un sous-groupe d'utilisateurs pour avoir leur retour d'expérience et on se fait matraquer la tête car on a rien compris à leur besoin et que ça ne marche pas comme ça devrait
7- on recommence...
8-...et au bout d'un certain temps, après avoir refait plusieurs petits tours de manège dans ce "cycle en V" puis finalement passé avec plus ou moins de succcès les fourches caudines de l'intégration, et celles du service de sécurité du SI, on met en production...Alléluhia!

Certains se sont dits, "ça ne peut pas durer!"...alors on a inventé les méthodes agiles...c'était mieux, mais ça prenait encore pas mal de temps car on sortait d'une approche monolithique au profit d'une approche itérative plus courte et efficace. Pour autant, ça ne réglait pas tous les problèmes puisqu'on butait encore sur le temps de mise en production. L'infra allait plus vite, le développement aussi, mais pas tellement la capacité à "releaser" de nouvelles applications beaucoup plus vite, car les environnements de Dev, Test, Intégration, Prod restaient encore bien séparés et il y avait toujours des différences - souvent importantes - entre ces environnements. Du coup, on avait des phénomènes du type “ça marche bien en intégration mais pas en pré-prod”

Et puis, il y a moins de 15 ans, avec l'essor d'Internet comme notre nouveau bureau personnel et professionnel, tout le monde a commencé à faire de la Transformation Digitale. C'est peut-être une des expressions encore aujourd'hui les plus utilisées dans les entreprises.

Pour soutenir cette transformation, les départements informatiques ont été jugés bien trop lents et trop chers, et les grands hyperscalers américians (AWS, GCP, AZURE) et d’autres éditeurs dits de SaaS/PaaS/IaaS, ont été jugés bien plus performants à tous points de vue. Aujourd’hui, c’est le règne du Cloud pour soutenir la transformation digitale ! C’est même le règne du Multi-Clouds!

Au fait, c'est quoi exactement la transformation digitale?

L'idée est super simple et l'objectif - comme souvent - se mesure en $.

Jusqu'à la fin des années 1990, presque tout le business d'une entreprise reposait sur des relations physiques avec son ecosystème. La vente se faisait essentiellement en magasin pour les particuliers, des commerciaux se déplaçaient chez leurs clients professionnels pour leur présenter puis vendre leurs produits et services, les logiciels dont on avait de plus en plus besoin dans nos processus métiers étaient installés dans nos datacenters en propre (on-premise). Certes, il y avait déjà les premiers magasins en ligne tels Amazon, PriceMinister, CDiscount et quelques autres commençaient à faire parler d'eux mais les grandes banques, assurances, les retailers, les CPG, les telco, les industriels, et surtout les professionnels de plus en plus nombreux de l'informatique ne parlaient pas de transformation digitale ni de Cloud. La première fois qu'on a pu consulter ses comptes bancaires en ligne sur Internet remonte à 1995 (banque directe), et presque toutes les banques proposaient ce service dès l'an 2000! Pourtant, les banques ont été les plus précurseurs sur le sujet, ce qui nous rappelle à quel point tout ceci est encore assez récent!

Beaucoup ont laissé passer le train de l'internet, puis de l'internet mobile. Et tout le monde, quelque soit son métier, s'est réveillé en même temps, avec le même mot d'ordre "si l'on ne fait rien, on va se faire ubériser par des nouveaux entrants, puis on va disparaître". C'est la célèbre phrase prononcée par Maurice Levy, patron de Publicis, qui expliquait lors d'un entretien "Tout le monde a peur de se faire ubériser".

La transformation digitale et son déferlement numérique étaient nés et avec eux des investissement massifs dans tous les domaines d'activités pour transformer l'entreprise en "Digital Company" afin d'exploiter les opportunités infinies qu'offrait Internet.

Ainsi, le Cloud est devenu la règle et avec lui, de nouvelles compétences en tous genres étaient requises. Un exemple: les API (vous savez le "bout" de code réutilisable pour permettre à une application de s'exposer à d'autres applications). En effet, il fallait bien trouver un moyen (sur Internet) de connecter des applications internes et externes avec les autres applications et services utilisés, sachant que tout ce petit beau monde n'avait pas été conçu pour discuter ensemble. Et puis, les API, c'est génial pour écrire un petit service informatique qu'on peut réutiliser autant de fois qu'on veut dans de plus gros services informatiques. Oui, mais, pour mettre en place des API SOAP puis REST (et maintenant Graph QL), il était nécessaire de réécrire un bout des applications existantes pour les "APIser" et pour cela il fallait encore plus de développeurs.

Bon, à ce stade, les bases étaient posées, Devops n'existait pas encore mais avec le Cloud son avènement devenait inéluctable !

La nouvelle mentalité "Fast & Furious"

On aurait pu en rester là, mais nous sommes alors entrés dans l'ère des réseaux sociaux, où tout va vite, beaucoup plus vite. A l’instar de l’information (une actualité chasse l’autre), une application chasse l’autre. C’est une course contre la montre pour développer et produire des services (presque toujours web) toujours plus rapidement, en continu, avec l’idée que - dans un monde digitalisé et pressé - la vitesse (le Time To Market pour les initiés) est devenue le critère absolu.

Il fallait donc trouver un moyen d’accélérer encore. Et c’est donc ça DevOps, un ensemble de méthodes, pratiques et outils pour développer et produire des services informatiques très vite et en continu grâce à une automisation toujours plus grande.

Pour cela, il fallait que les développeurs puissent presque tout faire tout seul, et comme ce sont des développeurs, il fallait que tout soit sous forme de code, même la création des infrastructures sous-jacentes à l'exécution du code applicatif métier. On est entré dans l’ère du « You Build it, You Run it ». C’est le « Shift Left » accompagné de son automatisation la plus aboutie (Pipelines CI/CD). Le développeur peut tout faire tout seul. Adieu, les silo Dev/Test/Intégration/Production, vous n'êtes plus adaptés à notre Time-to-Market!

Ainsi, il fallait définitivement casser les silos Développement/Production.

On a tous vu cette magnifique illustration de DevOps. Une boucle qui automatise le cycle de développement logiciels en traversant toutes les étapes de création, tests, intégration, déploiement et pilotage d’applications

En général, quand on utilise le symbole de l’infini (le fameux lemniscate), j’ai toujours le sentiment qu’on me « vend » un truc automatisé de bout en bout, un peu comme une chaîne de fabrication industrielle parfaitement huilée avec un minimum d’interventions humaines. Ca a l'air magique !

En réalité, ce n’est pas si simple (il fallait s’y attendre) et pas magique du tout !

Prenons, par exemple, le sujet de la sécurité dont nous n'avons pas encore parlé, et dont tout le monde comprend qu’il est essentiel compte tenu du contexte réglementaire croissant et plus largement de l’explosion de cybermenaces en tous genres sur Internet.

Donc, la sécurité en question…

Jusqu’à alors, on avait un(e) RSSI (responsable de la sécurité des systèmes d’information) qui – dans une approche souvent top down, un peu autoritaire mais très salutaire – essayait, avec ses équipes, d’imposer des bonnes pratiques aussi bien au niveau de l’infra, du code, de l’accès à toutes ces ressources ou encore de la nature des communications permises entre les services (réseau). Il/Elle était souvent perçu(e) comme l’empêcheur de tourner en rond, le gardien du temple qui met des bâtons dans les roues de ses petits collègues notamment les développeurs. C’était déjà assez compliqué comme cela, mais comme les équipes travaillaient en silos, il y avait encore moyen d’imposer des règles d’hygiène élémentaires de sécurité, d'autant que les COMEX avaient commencé à comprendre que la sécurité était un vrai sujet sérieux. Quand un développeur demandait - à travers un catalogue de services - un serveur (souvent une machine virtuelle), avec une version spécifique d’un système d’exploitation, et une base de données quelconque, il/elle ouvrait un ticket et sa demande passait par les fourches caudines des équipes d’infrastructure. Ce qui était livré – souvent de manière automatique et instantanée - incluait des petits programmes appelés agents dont la majorité permettait de forcer ou a minima surveiller les processus qui s’exécutaient sur le serveur, les flux de communication, etcetera. Du point de vue de la sécurité, c’était encore gérable.

On a compris que grâce à DevOps, les développeurs deviennent les maîtres du royaume de l’IT, puisqu’ils sont maintenant en charge de toute la chaîne de développement jusqu’à la mise en production.

Pour bien comprendre ce changement de paradigme, j’ai récupéré une illustration réalisée par la société Snyk, éditeur de logiciels bien connu des spécialistes dits de sécurité des applications cloud

Cette image illustre assez bien ce changement. Dans l’ère du Cloud et du DevOps, qu’on appelle aussi Cloud Native, on comprend que dorénavant les décisions de sécurité appartiennent d'abord aux développeurs !

Il faut donc fournir aux développeurs (dont on rappelle que la principale préoccupation est de livrer du code de qualité le plus vite posssible) un ensemble de méthodes et outils pour leur permettre de gérer seuls la sécurité du tout. Il est rare qu’un développeur ne soit pas conscient des enjeux sécuritaires, mais il est encore plus rare qu'il soit un spécialiste de la sécurité du SI.

Donc, on reprend....la sécurité doit être embarquée dès les phases en amont de code/développement (le fameux shift left).

On ne rentrera pas dans le détail de ces solutions ici, mais sachez que les outils et méthodes sécuritaires utilisés auparavant sont devenus largement obsolètes. Cela a donné naissance à une série de solutions logicielles qu’on appelle SCA, SAST, DAST, CNAPP, et encore beaucoup d’autres acronymes qui rentrent tous dans la grande famille de l'« Application Security Solutions », la sécurité des applications cloud, et dont l’objectif est de sécuriser le code, ses dépendances et bien entendu son exécution dans les fameux containers (Docker étant le plus connu) eux-mêmes orchestrés par le non moins fameux Kubernetes, sans qui rien n’est possible.

Si on devait résumer, il faut tout protéger mais différemment car tout est devenu CODE, à la main et sous la responsabilité du développeur. Aujourd’hui, le déploiement d’une infrastructure et de ses configurations se fait de manière automatisée par des lignes de code (yaml par exemple), avec plusieurs solutions pour y parvenir, même si les plus utilisées restent Terraform et Ansible. C’est le fameux Infrastructure as code.

On peut - pour préparer mon prochain article - citer quelques solutions de sécurité devops (DevSecOps) qui ont pignon sur rue : Sysdig, Wiz, AccuKnox, Prisma Cloud, Snyk ou encore Veracode.

Rassurez-vous, je n'en dirai pas plus dans cet article destiné aux non-informaticiens, mais pour ceux que cela intéresse, je vais donc bientôt écrire un article un chouïa plus technique sur la myriade de solutions qui ont vu le jour autour de DevOps et DevSecOps.

A ce stade, certains d’entre vous - déjà un peu au fait du sujet - s’interrogeront sur l’absence d’acteurs majeurs dans cet article tels GitLab ou GitHub.

Ces derniers sont fondamentaux dans la chaîne DevOps et proposent des options de sécurité plus ou moins intégrées. En réalité, ils sont d’abord utilisés comme des Repositories, les fameux REPO, là où les développeurs déposent leurs codes, et toutes les sous-branches (un peu comme un arbre de versions de code). Et c’est au niveau du REPO que la sécurité commence. Il y a d’ailleurs 5 briques fondamentales de code à sécuriser : le code du développeur, le code open source et ses dépendances (souvent plus de 50% du code utilisé par les développeurs provient de codes sources libres de droits), les containers & l’orchestrateur, et enfin l’infrastructure as code, et le Pipeline CI/CD (qui a tous les droits ou presque)

Donc, tout démarre dans le REPO et tout recommence dans le REPO, y compris la sécurité... il est donc très important que ces derniers soient correctement protégés ! La presse spécialisée se fait régulièrement l'écho de codes sources subtilisés dans des REPO d’entreprise, car la gestion des accès est souvent très largement insuffisante.

Le REPO c’est le temple, c’est sacré ! On ne doit pas pouvoir rentrer n'importe comment dans un temple ! Il faut montrer patte blanche.

Conclusion

J’espère que ce petit tour d’horizon non technique, et très « high level » (comme on dit), permettra à certains de mieux comprendre les changements de paradigme profonds en cours au sein de l’informatique et plus largement au sein des entreprises. Il est à peine exagéré de dire que toutes les entreprises deviennent des entreprises digitales, dont la croissance, l’avenir et peut-être même la survie dépendent de plus en plus de leur capacité à délivrer de nouveaux services rapidement. DEVOPS, CLOUD SECURITY, et CLOUD NATIVE sont des termes que vous n’avez pas fini d’entendre et avec eux leur cortège de solutions en tous genres pour arriver à une seule destination : « You build it, You run it, Securely ».

A titre personnel, n’étant pas informaticien d’origine mais baignant dans le monde informatique depuis (trop) longtemps, il m’a fallu du temps pour comprendre ces sujets, et surtout comprendre d’où ils viennent et ainsi mieux anticiper ce qui arrive !

J'espère que cette lecture aura su conjuguer l'utile à l'agréable.

Nicolas Petroussenko

Disclamer: Bien entendu, ce comparatif est le fruit de notre analyse, et repose sur les éléments en notre possession. Il se peut qu’il soit parfois incomplet voire incorrect. Il a pour seul objectif de partager un point de vue à la suite d’une analyse et de tests réalisés sur ces solutions.

1. Zscaler

• SASE : Zscaler propose une plateforme complète de SASE avec Zscaler Internet Access (ZIA) et Zscaler Private Access (ZPA) pour les applications internes.

• ZTNA : Zscaler utilise ZTNA pour contrôler l'accès aux applications, en passant par un cloud privé pour sécuriser les connexions.

• Avantages :

  • Réseau mondial de data centers offrant une faible latence.

  • Fortes capacités de sécurité (inspection SSL, protection contre les menaces).

• Inconvénients :

  • Tarification élevée pour les petites entreprises.

  • Complexité de configuration et de gestion.

2. Cisco (Umbrella et Duo)

• SASE : Cisco propose Cisco Umbrella pour les fonctionnalités de sécurité dans le cloud, combiné à Cisco SD-WAN pour la gestion du réseau.

• ZTNA : Cisco Duo permet une authentification multi-facteurs et des contrôles d’accès basés sur les appareils et utilisateurs.

• Avantages :

  • Facilement intégrable avec les autres solutions Cisco.

  • Interface conviviale et rapports de sécurité détaillés.

• Inconvénients :

  • Cisco Umbrella peut être coûteux pour des réseaux très étendus.

  • Besoin de formation pour gérer efficacement les multiples composants.

3. Palo Alto Networks (Prisma Access)

• SASE : Prisma Access de Palo Alto propose une solution SASE très intégrée avec des fonctions avancées de prévention des menaces et de gestion des identités.

• ZTNA : Leur approche ZTNA permet un accès granulaire basé sur les identités et les appareils.

• Avantages :

  • Excellente visibilité sur les menaces et analytics.

  • Intégration avec le reste des solutions Palo Alto pour une sécurité renforcée.

• Inconvénients :

  • Complexité dans la mise en œuvre initiale.

  • Coût élevé pour des fonctionnalités avancées.

4. Netskope

• SASE : Netskope propose une architecture SASE bien développée, intégrant CASB (Cloud Access Security Broker), ZTNA, et des services de sécurité web.

• ZTNA : Son approche ZTNA est centrée sur l'inspection en temps réel des données et le contrôle des applications.

• Avantages :

  • Optimisé pour les environnements multi-cloud et les applications SaaS.

  • Interface utilisateur intuitive et analytics puissants.

• Inconvénients :

  • Performance impactée pour certaines connexions à longue distance.

  • Intégrations limitées avec des produits de sécurité tiers.

5. Cloudflare (Cloudflare for Teams)

• SASE : Cloudflare propose un modèle SASE via Cloudflare One, incluant un proxy réseau et un pare-feu de nouvelle génération.

• ZTNA : Cloudflare Access permet une approche ZTNA simplifiée pour sécuriser les applications sans nécessiter de VPN.

• Avantages :

  • Très haute performance pour les utilisateurs à distance.

  • Solution simple à déployer pour les entreprises de toutes tailles.

• Inconvénients :

  • Moins de fonctionnalités avancées que certains concurrents.

  • Peut nécessiter des compléments pour des besoins très spécifiques en sécurité.

6. Cato Networks

• SASE : Cato Networks propose une plateforme SASE complète intégrant SD-WAN, sécurité réseau et accès cloud via un backbone privé mondial. Cato Networks

• ZTNA : Leur solution Universal ZTNA offre un contrôle d'accès basé sur l'identité et le contexte, appliqué de manière cohérente sur l'ensemble des environnements: Cato Networks

• Avantages :

  • Réseau privé mondial offrant une faible latence et une haute disponibilité.

  • Gestion centralisée avec une interface unifiée pour les politiques de sécurité et de réseau.

  • Évolutivité permettant de s'adapter aux besoins croissants des entreprises.

• Inconvénients :

  • Moins de reconnaissance de la marque par rapport à certains concurrents établis.

  • Peut nécessiter une période d'adaptation pour les équipes IT habituées à des solutions traditionnelles.

7. Perimeter 81

• SASE : Perimeter 81 offre une plateforme SASE intégrée, combinant des fonctionnalités de réseau et sécurité en une solution cloud unique: Perimeter 81 (nouvellement rebaptisée Harmony SASE depuis le rachat de la société par Check Point)

• ZTNA : La solution propose un accès réseau basé sur le modèle Zero Trust, accordant des permissions en fonction de l'identité de l'utilisateur et du contexte: Perimeter 81. C’est donc un sérieux avantage quand on a déjà travaillé sur la gestion des identités et des accès avec un IdP.

• Avantages :

  • Déploiement rapide, souvent en moins d'une heure.

  • Gestion centralisée avec une interface intuitive.

  • Intégration avec des fournisseurs d'identité tels qu'Okta, Azure AD et OneLogin.

• Inconvénients :

  • Certaines fonctionnalités avancées, comme la prévention des pertes de données (DLP), peuvent être moins développées.

  • Intégrations tierces moins nombreuses ou moins profondes que celles proposées par d'autres fournisseurs.

Tableau récapitulatif

L’équipe SASE/ZTNA Point Base (www.pointbase.fr)

Okta est une entreprise spécialisée dans la gestion de l'identité et de l'accès, offrant une gamme complète de solutions pour l'authentification, l'autorisation et la gestion des utilisateurs. Pour notre sujet d'aujourd'hui, nous nous concentrerons sur la composante "authentification" d'Okta. Elle joue un rôle essentiel dans la sécurisation de l'accès à notre application Angular, offrant une solution robuste pour garantir la sécurité des utilisateurs.

Configuration et Intégration de l'authentification Okta à Angular

I. Configuration de notre solution d’authentification sur Okta

Si vous ne disposez pas d'un compte Okta, vous devez créer un compte avec votre e-mail professionnel. Pour ce faire, rendez-vous sur le site web d'Okta et suivez les instructions pour créer un compte. Une fois connecté, cliquez sur le bouton "ADMINISTRATION", puis sur l'onglet "Applications", ensuite sur le sous-onglet "Applications", vous aurez une vue comme suit :

Maintenant, nous allons créer une "App Integration" (intégration d'application) qui nous permettra de lier spécifiquement notre application Angular à la plateforme Okta. Pour ce faire, cliquez sur "Create App Integration", vous obtiendrez une vue comme celle-ci :

Lors de cette étape, nous devons spécifier deux éléments essentiels : la "méthode d'authentification" (sign-in method) et le "type d'application" à intégrer. Nous choisissons OIDC (OpenID Connect) comme méthode d'authentification en raison de ses avantages, notamment l'authentification unique (Single Sign-On), la sécurité basée sur OAuth 2.0 et l'utilisation de JWT (JSON Web Tokens). Quant au "type d'application", nous optons pour "Single-Page Application" en raison de la nature d'Angular, qui est une application de type Single-Page Application.
Cliquez ensuite sur "Next".

Sur cette page, nous avons saisi des informations dans les champs suivants :

1. App Integration Name : Il s'agit du nom de votre intégration d'application.

2. Grant type : Ce champ permet de spécifier la méthode par laquelle une application peut obtenir un jeton d'accès pour interagir avec une API ou un service. Dans notre cas, nous allons utiliser le flux d'autorisation par code d'autorisation (Authorization Code), qui est considéré comme la méthode la plus sécurisée.

3. Sign-in redirect URIs : Ici, vous devez indiquer les URL de redirection une fois que l'utilisateur a été authentifié sur Okta. Dans notre cas, nous avons configuré cette URL comme http://localhost:4200/login/callback. Veuillez noter que nous avons utilisé le port par défaut d'Angular, mais si vous avez modifié le port par défaut d'Angular, assurez-vous de renseigner le port correct.

4. Sign-out redirect URIs : Cette option est similaire à "Sign-in redirect URIs", mais elle concerne la déconnexion. Ici, nous avons renseigné http://localhost:4200/login pour rediriger l'utilisateur vers la page de connexion (chemin '/login') après sa déconnexion.

5. Assignements : Dans ce champ, vous spécifiez les personnes autorisées à s'authentifier pour utiliser votre application. Dans notre cas, nous avons choisi "Limit access to selected groups" pour indiquer que seuls les utilisateurs du groupe que nous avons créé dans Okta seront autorisés à s'authentifier et à utiliser notre application. Cependant, vous pouvez choisir de spécifier les utilisateurs ou groupes ultérieurement.

Il est essentiel de noter que ces informations sont cruciales pour configurer correctement votre intégration d'application et définir qui peut y accéder. Une fois enregistrées, vous aurez besoin des informations suivantes pour lier cette intégration à votre application Angular :

• issuer : 'votre-domain/oauth2/default'

• clientId : 'votre identifiant client' (visible directement dans l'onglet général de l'intégration que vous venez de créer)

• redirectUri : 'URL' (l'URL que vous avez précédemment fournie pour le champ "Sign-in redirect URIs")

• postLogoutRedirectUri : 'URL' (l'URL que vous avez précédemment fournie pour le champ "Sign-out redirect URIs")

Veuillez noter que pour trouver votre domaine, vous pouvez cliquer sur votre adresse e-mail en haut de la page, où vous verrez votre domaine, par exemple, "trial-###...###.okta.com" (dans le cas d'un domaine d'essai).

Après avoir pris note de ces informations essentielles, nous pouvons désormais passer à la deuxième étape : l'intégration dans notre application Angular

II. Intégration de notre solution d'authentification à Angular

Assurez-vous d'avoir créé votre application Angular. Une fois cela fait, installez les packages suivants :

npm install @okta/okta-auth-js

npm install @okta/okta-angular

Ajoutez le code suivant à votre fichier /src/environments/environment.ts, en remplaçant les valeurs par celles que vous avez notées précédemment :

•       export const environment = {
          production: false,
          oktaAuth :{
          issuer: 'https://trial-34##....#718.okta.com/oauth2/default',
          clientId: '08rp####....###w697',
          redirectUri: 'http://localhost:4200/login/callback',
          postLogoutRedirectUri: 'http://localhost:4200/login',
          devMode: true,
          }
        };
  

Note : Nous avons ajouté "devMode: true" pour afficher dans la console l'objet retourné contenant les informations de l'utilisateur et le jeton. Cette option peut être utile si vous prévoyez de traiter ces informations, car elle permet de visualiser la structure de l'objet retourné.

À présent, dans le fichier app.module.ts, nous allons importer la variable d'environnement et configurer le module OktaAuthModule.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';
import { OktaAuthModule, OKTA_CONFIG } from '@okta/okta-angular'; // import OktaAuthModule
import { OktaAuth } from '@okta/okta-auth-js';
import { HttpClientModule } from '@angular/common/http';
import {environment} from '../environments/environment' // import environment


// ici crée un objet de type OktaAuth, et on initialise avec 
// les données que nous avont recuperé depuis Okta 
const oktaAuth = new OktaAuth(environment.oktaAuth); 

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule,
    OktaAuthModule.forRoot({ oktaAuth }), //ici on configure avec notre objet OktaAuth 
    HttpClientModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

NB : Assurez-vous que les informations que vous renseignez ici correspondent à celles fournies dans la configuration sur Okta précédemment.

Maintenant, nous allons mettre en place les fonctions de connexion et de déconnexion. Pour ce faire, j'ai ajouté trois composants : Home, Navbar et Login. Le composant Home contient la page d'accueil où l'utilisateur arrive une fois authentifié. Sur cette page, un bouton de déconnexion est placé dans la Navbar (qui apparaît sur la page Home) pour permettre la déconnexion et envoyer une demande de révocation du jeton d'authentification. Le composant Login contient le bouton d'authentification.

Afin de sécuriser les routes de notre application, nous avons utilisé des guards. Vous pouvez les générer en utilisant la commande suivante :

ng generate guard gurads/OktaAuth

Les codes d'implémentations de ces différents composants :

navbar.component.html

<nav class="navbar navbar-expand-lg navbar-light bg-light">
     <div class="container">
          <a class="navbar-brand" href="#">Gui-App</a>
          <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarNav"
               aria-controls="navbarNav" aria-expanded="false" aria-label="Toggle navigation">
               <span class="navbar-toggler-icon"></span>
          </button>
          <div class="collapse navbar-collapse" id="navbarNav">
               <ul class="navbar-nav">
               </ul>
          </div>
          <ng-container *ngIf="(isAuthenticated$ | async) === false">
               <button class="btn btn-sm btn-outline-primary ml-auto" (click)="signIn()"> Sign in </button>
          </ng-container>


     </div>
</nav>

navbar.component.ts

import { DOCUMENT } from "@angular/common";
import { Component, Inject, OnInit } from "@angular/core";
import { Router } from "@angular/router";
import { OktaAuthStateService, OKTA_AUTH } from "@okta/okta-angular";
import { AuthState, OktaAuth } from "@okta/okta-auth-js";
import { filter, map, Observable } from "rxjs";

@Component({
  selector: 'app-navbar',
  templateUrl: './navbar.component.html',
  styleUrls: ['./navbar.component.css']
})
export class NavbarComponent implements OnInit {
  public isAuthenticated$!: Observable<boolean>;
  constructor(
    private _router: Router,
    private _oktaStateService: OktaAuthStateService,
    @Inject(OKTA_AUTH) private _oktaAuth: OktaAuth
  ) {}

  public ngOnInit(): void {
    this.isAuthenticated$ = this._oktaStateService.authState$.pipe(
      filter((s: AuthState) => !!s),
      map((s: AuthState) => s.isAuthenticated ?? false)
    );
  }

  public async signIn(): Promise<void> {
    try {
      await this._oktaAuth.signInWithRedirect();
    } catch (error) {
      console.error("Error during sign-in:", error);
    }
  }


}

home.component.html

<div class="">
    <app-navbar></app-navbar>
    <div class="login-page">
        <div class="login-cover"></div>
        <div class="login-content">
            <p><span class="text-primary">{{userName}} ({{userEmail}})</span> Bienvenue dans votre espace securisé</p>
        </div>
    </div>
</div>

home.component.ts

import { DOCUMENT } from "@angular/common";
import { Component, Inject, OnInit } from "@angular/core";
import { Router } from "@angular/router";
import { OktaAuthStateService, OKTA_AUTH } from "@okta/okta-angular";
import { AuthState, OktaAuth } from "@okta/okta-auth-js";
import { filter, map, Observable } from "rxjs";

@Component({
  selector: "app-home",
  templateUrl: "./home.component.html",
  styleUrls: ["./home.component.css"],
})
export class HomeComponent implements OnInit {
  userName: string = "";
  userEmail: string = "";

  constructor(
    private _router: Router,
    private _oktaStateService: OktaAuthStateService,
    @Inject(OKTA_AUTH) private _oktaAuth: OktaAuth,
    @Inject(DOCUMENT) private _document: Document
  ) {}

   ngOnInit(): void {
    this._oktaStateService.authState$
      .pipe(
        filter((authState) => !!authState && !!authState.isAuthenticated), // Vérification de nullité
        map((authState) => authState?.idToken?.claims) // Récupère les informations de l'utilisateur depuis le jeton
      )
      .subscribe((userClaims) => {
        if (userClaims) {
          // Les informations de l'utilisateur, telles que le nom et le prénom, sont stockées dans les "claims" du jeton
          this.userName = `${userClaims.name}`;
          this.userEmail = `${userClaims.email}`;
        }
      });
  }
}

login.component.html

<div class="login-page">
     <div class="login-cover"></div>
     <div class="login-content">
          <h1>Bienvenue sur Gui-App</h1>
          <p>Veuillez vous authentifier pour accéder à votre espace sécurisé.</p>
          <button class="  btn btn-sm btn-outline-primary ml-auto" (click)="signIn()">S'authentifier</button>
     </div>
</div>

login.component.ts

import { DOCUMENT } from "@angular/common";
import { Component, Inject, OnInit } from "@angular/core";
import { Router } from "@angular/router";
import { OktaAuthStateService, OKTA_AUTH } from "@okta/okta-angular";
import { AuthState, OktaAuth } from "@okta/okta-auth-js";
import { filter, map, Observable } from "rxjs";

@Component({
  selector: 'app-login',
  templateUrl: './login.component.html',
  styleUrls: ['./login.component.css']
})
export class LoginComponent implements OnInit {

  constructor(
    private _router: Router,
    private _oktaStateService: OktaAuthStateService,
    @Inject(OKTA_AUTH) private _oktaAuth: OktaAuth,
    @Inject(DOCUMENT) private _document: Document
  ) {}

  ngOnInit(): void {
    // vavigate vers home si user connecter
    this._oktaStateService.authState$.subscribe((authState) => {
      if (authState.isAuthenticated) {
        this._router.navigate(["/home"]);
      }
    });
  }

    public async signIn(): Promise<void> {
    try {
      await this._oktaAuth.signInWithRedirect();
    } catch (error) {
      console.error("Error during sign-in:", error);
    }
  }

}

okta-auth.guard.ts

import { Injectable, Inject, OnInit  } from "@angular/core";
import {
  ActivatedRouteSnapshot,
  CanActivate,
  RouterStateSnapshot,
  UrlTree,
  Router,
} from "@angular/router";
import { AuthState, OktaAuth } from "@okta/okta-auth-js";

import { OktaAuthStateService, OKTA_AUTH } from "@okta/okta-angular";
import { filter, map, Observable } from "rxjs";

@Injectable({
  providedIn: "root",
})
export class OktaAuthGuard implements CanActivate {

  //  public isAuthenticated$!: Observable<boolean>;

  constructor(
    private _router: Router,
     private _oktaStateService: OktaAuthStateService,
    @Inject(OKTA_AUTH) private _oktaAuth: OktaAuth
  ) {}


  canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean> {
    return this._oktaStateService.authState$.pipe(
      filter((s) => !!s),
      map((authState) => {
        if (!authState.isAuthenticated) {
          // Si l'utilisateur n'est pas authentifié, redirigez-le vers la page de connexion.
          this._router.navigate(["/login"]);
          return true;
        }
        return true;
      })
    );
  }
}

app-routing.module.ts

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { OktaCallbackComponent } from '@okta/okta-angular';
import { HomeComponent } from './components/home/home.component';
import { LoginComponent } from './components/login/login.component';
import { OktaAuthGuard } from './gurads/okta-auth.guard';

const routes: Routes = [
  { path: 'login/callback', component: OktaCallbackComponent }, 
  { path: 'home', component: HomeComponent, canActivate: [OktaAuthGuard]},
  { path: 'login', component: LoginComponent},
  { path: '', redirectTo: '/home', pathMatch: 'full' },
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Si tout se passe bien et que vous démarrez votre application Angular, vous verrez une page qui ressemble à ceci, si vous avez ajouté les styles CSS et Bootstrap :

Lorsque vous cliquez sur le bouton "S'authentifier", vous serez redirigés vers la page d'authentification Okta, qui ressemble à ceci :

Dans mon cas, il existe déjà un compte actif associé à l'adresse e-mail martin.luc@test.com, auquel nous avons précédemment assigné, via un groupe Okta, à notre "intégration d'application" que nous avons configurée. Assurez-vous de renseigner un utilisateur actif qui est également assigné à votre intégration d'application.

Lorsque vous cliquez sur "Suivant", si c'est la première fois que l'utilisateur se connecte, il lui sera demandé de configurer Okta Verify, qui est une application d'authentification à deux facteurs (MFA) d'Okta. Okta Verify ajoute une couche de sécurité supplémentaire en générant un code de vérification temporaire à usage unique sur le smartphone de l'utilisateur. Ce code doit être saisi pour vérifier l'identité de l'utilisateur, renforçant ainsi la sécurité du processus de connexion. MFA (Multi-Factor Authentication) est une méthode efficace pour réduire les risques d'accès non autorisés en exigeant plus qu'un simple mot de passe pour l'authentification.

Une fois la configuration d'Okta Verify terminée, l'utilisateur peut désormais accéder de manière sécurisée à votre application. Il doit saisir son mot de passe une seule fois, lors de la première connexion. Cela démontre l'avantage du SSO (Single Sign-On), car lors de ses futures connexions, l'utilisateur sera simplement confirmé via l'application Okta Verify sur son téléphone. Il sera ensuite redirigé vers la page d'accueil de votre application, comme illustré ci-dessous :

Pour tester la déconnexion, vous pouvez cliquer sur le bouton "Se déconnecter". Le jeton d'authentification fourni par Okta sera révoqué, et vous serez déconnecté, puis redirigé vers la page de connexion.

Conclusion

En conclusion, l'intégration de l'authentification Okta dans votre application Angular constitue une étape cruciale pour garantir un accès sécurisé à vos utilisateurs. Avec Okta, vous bénéficiez d'une solution de gestion de l'identité et de l'accès qui gère la sécurité, l'authentification et l'autorisation (nous aborderons la partie autorisation dans un prochain article), vous permettant ainsi de vous concentrer sur le développement des fonctionnalités essentielles de votre application. Cela vous offre l'opportunité de fournir une expérience utilisateur fluide tout en renforçant la protection de vos ressources, tout en réduisant la charge liée à la gestion des identités. En exploitant les capacités d'Okta, vous pouvez garantir un accès sécurisé et offrir une tranquillité d'esprit à vos utilisateurs, tout en restant axé sur l'innovation et la croissance de votre application Angular.

Si vous croyiez connaître toutes les subtilités d'Okta, détrompez-vous ! Rejoignez Imad Bensisaid, architecte cloud chez UNi5 Technologies, et Faical Essalifi (Architecte cloud) dans cet épisode captivant du Podcast des Avengers où nous explorons l’univers fascinant d'Okta avec Laure-Anaïs de la société Point Base.

Dans cet article, nous explorerons des scénarios d'usage tels que l'auto-approvisionnement des configurations de sécurité, tout en scrutant également comment identifier des changements ainsi que les méthodes pour automatiser certaines configurations par défaut.

Un contrôleur d'admission est généralement déployé pour surveiller et, si besoin bloquer les configurations qui ne sont pas en accord avec les règles de conformité définies.

Se positionnant au centre des interactions avec le serveur kube-api, le contrôleur d'admission détient un accès complet à tous les appels API et, par conséquent, est apte à diriger des actions de mutation ou de génération, basées sur des règles précises. Cela permet une gestion exacte et automatisée des ressources et des configurations au sein d'un cluster Kubernetes. Génération automatique de politiques réseau et quotas.

Automatisation des configurations par defaut

Cette Clusterpolicy va automatiquement créer une networkpolicy ainsi qu'un resourcequotas dès que nous créerons un nouveau namespace

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: default-policy-and-quota
spec:
  rules:
  - name: create-default-network-policy
    match:
      resources:
        kinds:
        - Namespace
    generate:
      kind: NetworkPolicy
      name: default-network-policy
      namespace: "{{request.object.metadata.name}}"
      data:
        spec:
          podSelector: {}
          policyTypes:
          - Ingress
          - Egress
  - name: create-default-resource-quota
    match:
      resources:
        kinds:
        - Namespace
    generate:
      kind: ResourceQuota
      name: default-resource-quota
      namespace: "{{request.object.metadata.name}}"
      data:
        spec:
          hard:
            pods: "10"
            requests.cpu: "1000m"
            requests.memory: "1Gi"
            limits.cpu: "2000m"
            limits.memory: "2Gi"

Créons un namespace pour tester la policy:

ledan@vincent-Inspiron-7370:~/kyverno$ kubectl create ns top
namespace/top created

ledan@vincent-Inspiron-7370:~/kyverno$ kubectl get resourcequotas -n top

NAME                     AGE   REQUEST                                                 LIMIT
default-resource-quota   3s    pods: 0/10, requests.cpu: 0/1, requests.memory: 0/1Gi   limits.cpu: 0/2, limits.memory: 0/2Gi

ledan@vincent-Inspiron-7370:~/kyverno$ kubectl get networkpolicy -n top

NAME                     POD-SELECTOR   AGE
default-network-policy   <none>         11s

Une approche qui pourrait s'avérer intéressante consiste à appliquer cette action de manière rétroactive mais de façon maîtrisée.

Pour ce faire, nous allons activer l'option background: true.

Cela aura pour effet d'appliquer cette politique aux namespaces existants avec une spécificité : le "generate" ne se déclenchera qu'après une modification des namespaces (quelle qu'elle soit).

Pour faire preuve de prudence, nous allons également exclure certains namespaces de la règle en ajoutant

    exclude:
      resources:
        namespaces:
        - kube-system
        - kube-public
        - kyverno

Appliquons désormais la nouvelle clusterpolicy :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: default-policy-and-quota
spec:
  background: true
  rules:

  - name: create-default-network-policy
    match:
      resources:
        kinds:
        - Namespace
    exclude:
      resources:
        namespaces:
        - kube-system
        - kube-public
        - kyverno
    generate:
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      name: default-network-policy
      namespace: "{{request.object.metadata.name}}"
      data:
        spec:
          podSelector: {}
          policyTypes:
          - Ingress
          - Egress
  - name: create-default-resource-quota
    match:
      resources:
        kinds:
        - Namespace
      exclude:
        resources:
          namespaces:
          - kube-system
          - kube-public
          - kyverno
    generate:
      kind: ResourceQuota
      apiVersion: v1
      name: default-resource-quota
      namespace: "{{request.object.metadata.name}}"
      data:
        spec:
          hard:
            pods: "10"
            requests.cpu: "1000m"
            requests.memory: "1Gi"
            limits.cpu: "2000m"
            limits.memory: "2Gi"

À présent, nous allons attribuer des labels aux namespaces éxistant afin d'activer la politique :

ledan@vincent-Inspiron-7370:~/kyverno$ kubectl label namespaces ns1 ns2 ns3 ns4 ns5 trigger-kyverno-policy=v1
namespace/ns1 labeled
namespace/ns2 labeled
namespace/ns3 labeled
namespace/ns4 labeled
namespace/ns5 labeled

ledan@vincent-Inspiron-7370:~/kyverno$ kubectl get networkpolicy -n ns4
NAME                     POD-SELECTOR   AGE
default-network-policy   <none>         3s
ledan@vincent-Inspiron-7370:~/kyverno$ kubectl get networkpolicy -n ns3
NAME                     POD-SELECTOR   AGE
default-network-policy   <none>         5s

Si nous testons une modification sur le nom "kube-public", aucune action ne devrait être déclenchée :

ledan@vincent-Inspiron-7370:~/kyverno$ kubectl label namespaces kube-public  trigger-kyverno-policy=v1
namespace/kube-public labeled

ledan@vincent-Inspiron-7370:~/kyverno$ kubectl get networkpolicy -n kube-public
No resources found in kube-public namespace.

ledan@vincent-Inspiron-7370:~/kyverno$ kubectl label namespaces  default  trigger-kyverno-policy=v1
namespace/default labeled
ledan@vincent-Inspiron-7370:~/kyverno$ kubectl get networkpolicy -n default
NAME                     POD-SELECTOR   AGE
default-network-policy   <none>         5s

Il est bien sur possible d'aller plus loin avec des controles supplémentaires comme celui-ci. le controle ci-dessous fera en sorte de n'executer la policy uniquement si le namespace ne commence pas par admin.

    preconditions:
      - key: "{{request.object.metadata.name}}"
        operator: NotEquals
        value:  "admin*"

Testons quelques exemples:

:~/kyverno$ kubectl create ns yy
namespace/yy created

:~/kyverno$ kubectl get networkpolicy -n yy
NAME                     POD-SELECTOR   AGE
default-network-policy   <none>         5s

:~/kyverno$ kubectl create ns admin
namespace/admin created
:~/kyverno$ kubectl get networkpolicy -n admin
No resources found in admin namespace.

:~/kyverno$ kubectl create ns adminrrrrrrrr
namespace/adminrrrrrrrr created

:~/kyverno$ kubectl get networkpolicy -n adminrrrrrrrr
No resources found in adminrrrrrrrr namespace.

:~/kyverno$ kubectl create ns admi
namespace/admi created

:~/kyverno$ kubectl get networkpolicy -n admi
NAME                     POD-SELECTOR   AGE
default-network-policy   <none>         3s

Conclusion

Les possibilités sont aussi variées que les architectures elles-mêmes. La flexibilité et la puissance que ce puissant outil nous offre peuvent transformer non seulement comment nous gérons les configurations de sécurité, mais également comment nous envisageons l’automatisation au sein de nos clusters Kubernetes.

À titre d'exemple, imaginez la création automatisée de role bindings, ou de toute autre ressource et configuration, orchestrée de manière à s'aligner précisément avec les spécificités et les exigences de votre architecture.

Ainsi, qu'il s'agisse d’instancier des politiques de réseau, de définir des quotas ou d’automatiser la gestion des rôles et permissions, Kyverno nous offre un tableau sur lequel nous pouvons peindre, avec précision et habileté, les politiques de gestion et de conformité adaptées à notre environnement.

L'approche choisi est de bloquer directement les comportements arnormaux avant qu'ils ne se produisent sans impacter l'application.

KubeArmor est également utilisable en dehors de Kubernetes et s'installe sur des serveurs linux , Bare metal etc...

Points forts de KubeArmor

• Protection en temps réel : KubeArmor protège les conteneurs en temps réel, ce qui permet de bloquer les attaques dès qu'elles se produisent.

• Rémédiation en ligne : KubeArmor peut corriger les violations de sécurité en ligne, ce qui permet de réduire les dommages.

• Flexibilité : KubeArmor permet aux administrateurs de définir des politiques de sécurité personnalisées pour répondre aux besoins spécifiques de leur environnement.

• Simplicité : KubeArmor est facile à configurer et à utiliser.

• Performance : KubeArmor a un impact minimal sur les performances des conteneurs.

Différenciateurs

• Prise en charge de plusieurs LSM : KubeArmor prend en charge plusieurs modules de sécurité du noyau Linux (LSM), tels que AppArmor et Seccomp. Cela permet aux administrateurs de choisir l'LSM qui convient le mieux à leurs besoins.

• Audit et reporting : KubeArmor fournit des journaux d'audit et des rapports qui peuvent être utilisés pour surveiller l'activité des conteneurs.

• Intégration avec d'autres outils : KubeArmor peut être intégré à d'autres outils de sécurité, tels que SIEM et SOAR.

Kubearmor installation

Installons Kubearmor

helm repo add kubearmor https://kubearmor.github.io/charts
helm repo update kubearmor
helm upgrade --install kubearmor-operator kubearmor/kubearmor-operator -n kubearmor --create-namespace

et appliquon la CRD Kubearmor , pour notre exemple nous avons choisi une implémentation simple ( Documentation)

apiVersion: operator.kubearmor.com/v1
kind: KubeArmorConfig
metadata:
  labels:
    app.kubernetes.io/name: kubearmorconfig
    app.kubernetes.io/instance: kubearmorconfig-sample
    app.kubernetes.io/part-of: kubearmoroperator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: kubearmoroperator
  name: kubearmorconfig-default
  namespace: kubearmor
spec:
  defaultCapabilitiesPosture: audit
  defaultFilePosture: audit
  defaultNetworkPosture: audit
  defaultVisibility: process,file,network
  kubearmorImage:
    image: kubearmor/kubearmor:stable
    imagePullPolicy: Always
  kubearmorInitImage:
    image: kubearmor/kubearmor-init:stable
    imagePullPolicy: Always
  kubearmorRelayImage:
    image: kubearmor/kubearmor-relay-server
    imagePullPolicy: Always
  kubearmorControllerImage:
    image: kubearmor/kubearmor-controller
    imagePullPolicy: Always

Kubearmorpolicy implementation

Kubearmor fourni la possibilité de créer de nombreuses règles bloquant les syscall , le réseau , les capabilities kernel , les accès aux différents fichiers, les process.

Prenons quelques exemples

Process exemple : deny apt command

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-wordpress-block-process
  namespace: default
spec:
  severity: 3
  selector:
    matchLabels:
      app: nginx
  process:
    matchPaths:
    - path: /usr/bin/apt
    - path: /usr/bin/apt-get
  action: Block

Test :

vincn_ledan@cloudshell:~/kubearmor (medium-article)$ kubectl exec -it nginx-77b4fdf86c-vckbc -- bash 
root@nginx-77b4fdf86c-vckbc:/# apt
apt 2.6.1 (amd64)
Usage: apt [options] command

apt is a commandline package manager and provides commands for
searching and managing as well as querying information about packages.
It provides the same functionality as the specialized APT tools,
like apt-get and apt-cache, but enables options more suitable for
interactive use by default.

Most used commands:
  list - list packages based on package names
.........................................................

Apres application de la policy

incn_ledan@cloudshell:~/kubearmor (medium-article-377208)$ kubectl exec -it nginx-77b4fdf86c-vckbc -- bash 
root@nginx-77b4fdf86c-vckbc:/# apt
bash: /usr/bin/apt: Permission denied

File exemple : deny cat command

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-block-read
  namespace: default # use your namespace
spec:
  selector:
    matchLabels:
      app: nginx # use your labels here
  file:
    severity: 9
    matchPaths:
    - path: /etc/passwd
    action: Block

le résultat est le suivant :

I have no name!@nginx-77b4fdf86c-vckbc:/# cat /etc/hostname
nginx-77b4fdf86c-vckbc
I have no name!@nginx-77b4fdf86c-vckbc:/# cat /etc/passwd  
cat: /etc/passwd: Permission denied

Network Kubearmor policy

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-block-icmp
  namespace: default
spec:
  severity: 8
  selector:
    matchLabels:
      app: nginx
  network:
    matchProtocols:
    - protocol: icmp
  action:
    Block

Le résultat est le suivant :

I have no name!@nginx-77b4fdf86c-vckbc:/# ping 8.8.8.8
ping: 8.8.8.8: Address family for hostname not supported

Automatic policy discovery with Accuknox

Kubearmor fourni une feature très intérressante qui est l'application profiling afin de créer des policies custom basé sur le comportement des applications.

Nous allons utiliser la solution Accuknox pour ce faire et enregistrer simplement notre cluster GKE dans l'interface.

 helm upgrade --install accuknox-agents oci://public.ecr.aws/k9v9d5v2/accuknox-agents \
      --version "v0.1.5" \
      --set joinToken="REDACTED" \
      --set spireHost="REDACTED" \
      --set ppsHost="REDACTED" \
      --set knoxGateway="REDACTED" \
      -n accuknox-agents --create-namespace

En 1 ou 2 minutes l'agent discovery engine va analyser le comportement de l'application , les calls système et créer sur mesure une KubeArmorPolicy

Nous avons uniquement à activer la policy dans l'interface ou l'exporter et appliquer une logique Gitops.

Lorsque la policy est en mode innactive, le deamon va détecter les nouveaux calls système , accès aux fichiers et adapter de façon automatique la policy et demander si nous validons ou non ce nouveau comportement.

Next step

Dans un prochain article nous verrons les points suivants:

• Création automatique des networks policy avec Cilium et Kubearmor

• App behavior visibility

Le concept a été lancé avec la version 1.26 de Kubernetes et a atteint le stade beta dans la version 1.28.

L’un des points forts de cette fonctionnalité est son intégration directe à l’API de Kubernetes, éliminant le besoin de recourir à des tiers supplémentaires. Cela diminue ainsi l’effort requis pour la maintenance.

Validating Admission components

La logique de fond reste la même , si on prends l’exemple d’OPA par exemple :

Nous avons ces deux composants :

• ConstraintTemplate qui défini la logique de la policy et qui contient le controle en language Rego à éffectuer par exemple : “maximum de replicas d’un déploiement ne peux pas éxéder 5”

• Template utilise cette policy pour l’appliquer à tels ou tels composant POD , filtre la cible avec des parameters ….

Si on prends l’exemple de cette même policy mais pour la version native de Kubernetes , les composants principaux sont:

• ValidatingAdmissionPolicy qui défini la policy de controle mais cette fois ci en language CEL

• ValidatingAdmissionPolicyBinding est le même principe qu’un template il filtre le scope et parametre selon le contexte.

Validation admission controller in action

Afin de pouvoir tester cette feature, il est important d’avoir un environnement qui le permet. Minikube est vraiment intérressant pour tester de nouvelles Features comme celle-ci.

minikube start  --feature-gates='ValidatingAdmissionPolicy=true' \  
--kubernetes-version=1.28.0

Nous aimerions restreindre la possibilité de créer des services de type “NodePort” mais plutôt de centraliser l’exposition des applications avec un ingress ou un Kubernetes API gateway.:

Prenons maintenant un exemple avec OPA pour ce faire :

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sblocknodeport
  annotations:
    metadata.gatekeeper.sh/title: "Block NodePort"
    metadata.gatekeeper.sh/version: 1.0.0
    description: >-
      Disallows all Services with type NodePort.

      https://kubernetes.io/docs/concepts/services-networking/service/#nodeport
spec:
  crd:
    spec:
      names:
        kind: K8sBlockNodePort
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sblocknodeport

        violation[{"msg": msg}] {
          input.review.kind.kind == "Service"
          input.review.object.spec.type == "NodePort"
          msg := "User is not allowed to create service of type NodePort"
        }

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockNodePort
metadata:
  name: block-node-port
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Service"]

Maintenant voyons comment faire cette équivalent via l’admission controller natif de kubernetes :

Validatingadmissionpolicy:

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingAdmissionPolicy
metadata:
  name: deny-nodeport
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["services"]
  validations:
    - expression: object.spec.type != "NodePort"

Validatingadmissionpolicybinding:

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "vincent-binding-test.example.com"
spec:
  policyName: "deny-nodeport"
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        env: prod

Le Kind ValidatingAdmissionPolicyBinding va dans notre cas appliquer cette policy sur l’ensemble des namespaces ayant un label env=prod

Maintenant faisons un petit test en déployant un simple service NodePort dans un namespace ayant un label env=prod

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: toto
  name: toto
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: toto
  type: NodePort

kubectl apply -f service.yaml -n titi 

The services "toto" is invalid: 
: ValidatingAdmissionPolicy 'deny-nodeport' with binding 
'deny-service-nodeport' denied request: failed expression:
 object.spec.type != "NodePort"

Nous pouvons observer que la Requête à été bloquée par Kubernetes.

Conclusion

Cette feature n’est pas encore ready for production mais va dans le bon sens. si on compare à Kyverno par exemple , Kyvernoo offre plus de flexibilité ou d’automatisation , par exemple en fournissant la capacité a provisionner de façon automatique des kinds dans certains namespace.

Si on parle d’OPA , lui est utilisable dans bien d’autres contextes que Kubernetes , Policy as code , authentication on demand et beaucoup d’autres contextes.

Tout d’abord pourquoi proposons nous cela, la réponse est plutot simple, faire prendre conscience des problématiques ou mauvaises pratiques quant à la gestion et la sécurité dans ce types d’environnements.

Il est parfois facile de se perdre dans l’écosystème cloud natif sécurity , la sortie de nouveaux outils , des évolutions extrêmement rapides et complexes.

Notre Objectif est simple passer une journée avec vos équipes touchant de près ou de loin ce types écosystème ou nous repasserons en revue l’ensemble des problématiques de sécurité tant techniques mais également organisationnelles , les vecteurs d’attaques courants , les outils les plus pertinent , les dernières innovations , les bests practices dans le domaine et ce afin qu’a la fin de cette journée vous ayez une vision claire de la priorisation des efforts à mener.

Parfois cela pourra vous rassurer sur vos actions en cours , mais parfois cela vous fera probablement réfléchir de façon différente quant à la priorisation ou aux choix des outils.

Nous échangerons autour des problématiques réelles

Default cloud configuration :

Il est très courant que nos clients utilisent les configurations par défaut des providers, ou par exemple des modules terraform. Bien souvent, ces configurations ne sont pas suffisantes en termes de sécurité. Nous verrons pourquoi.

Networking :

Comme j’aime le rappeler, dans un cluster Kubernetes, tous les flux sont ouverts, non chiffrés et non contrôlés. Cela concerne les interactions entre les différents pods ou namespaces, mais aussi comment les pods peuvent communiquer avec l’extérieur ou scanner votre réseau VPC, entre autres. Un autre aspect concerne le contrôle des flux entrants et sa consolidation via des logiques d’ingress ou d’API gateway.

Admission controller et Gouvernance :

Dans un cluster Kubernetes, il est très facile de devenir admin, de corrompre les nœuds des clusters, car aucune restriction pour devenir root ou utiliser des capabilities avancées comme CAP_SYSADMIN n’est en place. La gestion des labels, la gouvernance, l’uniformité et la sécurité des déploiements, ainsi que leur protection au niveau du cluster doivent être implémentées.

Runtime protection / Sandboxing

Cette partie est souvent oubliée mais très importante. Par défaut, les hosts et l’activité des containers ne sont pas protégés contre des activités suspectes dans les containers (ex : cat /etc/…./credentials). Pour détecter ce genre d’activités, vous devez premièrement comprendre les risques et les possibilités des attaquants, mais également mettre en place un ensemble de règles pour détecter ou bloquer. Nous verrons plusieurs approches ensemble, par exemple “detection and response” ou “Block syscall”. Ce sont des décisions de sécurité.

3rd Party risks (argocd — gitlab…)

Bien que vous contrôliez la majeure partie de vos workloads tout au long de la chaîne, certaines composantes ne peuvent être contrôlées. Alors, quelle stratégie avez-vous adoptée ? Sandboxing container, cluster isolation, whitelist container registry ?

Surveillance et monitoring

Si nous faisons un focus sur les sujets de monitoring, plusieurs facteurs sont à prendre en compte. Que souhaitez-vous détecter ? Analyse comportementale des containers, activités suspectes sur le cluster, création de rôles RBAC suspects, activités suspectes sur vos buckets S3 ? Il y a beaucoup à dire sur le sujet.

Quotas et gestion des ressources

À la croisée des chemins entre les préoccupations des SRE et celles de vos équipes sécurité, il est crucial de contrôler à quel point et dans quelles conditions votre infrastructure peut évoluer (scale). Imaginons qu’un container soit compromis et souhaite perturber certains services. Êtes-vous en mesure, par exemple, de gérer et d’imposer des règles sur la consommation réseau de vos pods ?

Gestion des identités utilisateur et des workloads

Avoir une bonne gestion des droits et des groupes IAM n’est pas une nouveauté. Toutefois, comprendre les implications ou la puissance de certains “cluster roles”, par exemple (VERBS=GET, Kind=secret = Admin), est crucial. Trouver le juste milieu entre sécurité et flexibilité n’est pas toujours aisé.

Ce que l’on constate souvent, c’est une gestion inadéquate de l’authentification entre vos différents pods et des services cloud tels que DynamoDB, S3 buckets ou Cloud SQL chez GCP. Historiquement, l’utilisation des “access keys” intégrées secrètement était couramment utilisée. Toutefois, depuis un certain temps, les fournisseurs cloud ont développé des mécanismes permettant une approche plus granulaire et sans clé (ex : “workload identity” chez GCP).

Sécurité des workloads et des containers

Avez-vous mis en place des templates de déploiement ou des helm charts avec les configurations de sécurité les plus appropriées ? Comment vos images de containers sont-elles construites : multi-step, distroless, scan de vulnérabilités, scan du registre ? Comment priorisez-vous les dizaines de CVEs remontées par vos outils ? Autant de questions auxquelles nous réfléchirons.Cloud security

Votre flotte de clusters Kubernetes s’intégre logiquement dans une landing zone mais est-elle vraiment conçu pour être assez isoler , backuper vous vos clusters ? avez vous des procédures ou de l’automatisation pour déplacer vos workloads d’un cloud à un autre ?

Day2

Quand on parle de sécurité dans ce domaine, de nombreux outils open source sont efficaces. Cependant, assurez-vous d’avoir des équipes bien formées et suffisamment staffées pour garantir une continuité d’exploitation. Recourir sans cesse à de nouveaux outils pour pallier les manques d’autres n’est pas toujours la meilleure stratégie. Avez-vous mis en place des outils pour détecter les nouvelles CVEs exploitables dans vos workloads et des processus pour y remédier rapidement et à grande échelle ?

Sensibilisation à la sécurité offensive

Il est toujours intéressant d’adopter une perspective critique et offensive lors de la sécurisation d’un cluster. Comment pourrais-je contourner cette règle ? Comment pourrais-je compromettre notre CI/CD ? La gamification est un outil puissant pour changer les mentalités. Trois heures pour devenir administrateur du cluster : en discutons-nous ?

Nous discuterons plus en détail sur une série d’attque éffectuée sur des environnements Kubernetes : SCARLETEEL par exemple.

Gestion multi-cluster

Une fois que vous avez assimilé tous les points mentionnés précédemment, posez-vous la question : mes processus et mon architecture sont-ils adaptés à une montée en puissance ? Pensez à une échelle 100 fois supérieure. Mettez en œuvre davantage d’automatisation, une approche GitOps, et choisissez une source d’information unique.

Contactez nous dès maintenant pour avoir plus de détails.

Dans cet article, nous examinerons de plus près ce nouvel outil en mettant l’accent sur son déploiement ainsi que sur la création d’une règle personnalisée pour Falco. De plus, nous explorerons en détail l’interface utilisateur de Falco Sidekick UI, une addition bienvenue qui augmente la facilité d’utilisation de Falco.

Prérequis : Avoir un cluster Kubernetes en fonctionnement, avoir kubectl installé et installer helm.

Déploiement de Falco

Falco offre par défaut de nombreuses règles prédéfinies se basant sur les meilleures pratiques de sécurité les plus courantes. Dans le cadre de cet article, nous allons surcharger ces règles par défaut avec nos propres règles personnalisées. Pour ce faire, nous allons créer notre fichier custom-rules.yaml.

customRules:
  custom-rules.yaml: |-
    - rule: detect_ls_command
      desc: Detect execution de la commande 'ls' dans un conteneur
      condition: evt.type = execve and evt.dir = < and container.id != host and proc.name = ls
      output: "Execution de la commande 'ls' dans un conteneur (utilisateur=%user.name commande=%proc.cmdline)"
      priority: WARNING

    - rule: detect_date_command
      desc: Detect execution de la commande 'date' dans un conteneur
      condition: evt.type = execve and evt.dir = < and container.id != host and proc.name = date
      output: "Execution de la commande 'date' dans un conteneur (utilisateur=%user.name commande=%proc.cmdline)"
      priority: CRITICAL
    - rule: detect_whoami_command
      desc: Detecte execution de la commande 'whoami' dans un conteneur
      condition: evt.type = execve and evt.dir = < and container.id != host and proc.name = whoami
      output: "Execution de la commande 'whoami' dans un conteneur (utilisateur=%user.name commande=%proc.cmdline)"
      priority: ERROR

Dans ce fichier custom-rules.yaml, nous avons écrit 3 règles. La première a pour objectif de détecter l’exécution de la commande ls dans le shell d’un conteneur et d’envoyer une notification de priorité WARNING. Maintenant, passons à l’installation de Falco.

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
kubectl create ns falco

Dans la commande qui suit, nous procédons à l’installation de Falco et à l’activation de Falcosidekick. Cela nous offre une interface graphique et la possibilité d’envoyer des notifications sur les canaux spécifiés. Dans notre contexte, nous avons opté pour l’utilisation de Slack.

Note : Dans notre configuration, toutes les notifications d’un niveau supérieur ou égal à DEBUG seront transmises sur notre canal Slack.

helm install falco -n falco - namespace falco -f custom-rules.yaml - set driver.kind=ebpf - set tty=true falcosecurity/falco \
 - set falcosidekick.enabled=true \
 - set falcosidekick.webui.enabled=true \ 
 - set falcosidekick.config.slack.webhookurl=https://hooks.slack.com/services/REDACTED \
 - set falcosidekick.config.slack.minimumpriority=DEBUG \
 - set falcosidekick.config.customfields="user:barrybagata96"

On vérifie que tout s’est bien passé

$ kubectl get pods -n falco
NAME                                      READY   STATUS    RESTARTS   AGE
falco-7dvcj                               2/2     Running   0          3h44m
falco-cpd44                               2/2     Running   0          3h44m
falco-falcosidekick-54fffbc85b-f2xh2      1/1     Running   0          3h44m
falco-falcosidekick-54fffbc85b-nsfn5      1/1     Running   0          3h44m
falco-falcosidekick-ui-5ffc494bf8-b8wqk   1/1     Running   0          77m
falco-falcosidekick-ui-5ffc494bf8-pqzv6   1/1     Running   0          77m
falco-falcosidekick-ui-redis-0            1/1     Running   0          3h44m
falco-rsbqg                               2/2     Running   0          3h44m
falco-sl9j8                               2/2     Running   0          3h44m
barrybagata96@cloudshell:~/exo-falco (kubernetese-project-399608)$

Maintenant, testons les règles Falco que nous avons écrites dans custom-rules.yaml.

kubectl create deploy nginx --image=nginx

kubectl exec -it nginx-app-5c64488cdf-dnjm7 -- bash

root@nginx-app-5c64488cdf-dnjm7:/# ls
bin   dev                  docker-entrypoint.sh  home  lib32  libx32  mnt  proc  run   srv  tmp  var
boot  docker-entrypoint.d  etc                   lib   lib64  media   opt  root  sbin  sys  usr

kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco

..............................................................
..............................................................
                 logs filtrées
..............................................................
..............................................................

{"hostname":"falco-rsbqg","output":"12:11:59.619762538: 
Warning Ex\u00e9cution de la commande 'ls' dans un conteneur 
(utilisateur=root commande=ls) container_id=fca790abe8c7 
container_image=docker.io/library/nginx container_image_tag=latest 
container_name=nginx k8s_ns=default k8s_pod_name=nginx-app-5c64488cdf-dnjm7",
"priority":"Warning","rule":"detect_ls_command","source":"syscall","tags":[],
"time":"2023-09-28T12:11:59.619762538Z", "output_fields": 
{"container.id":"fca790abe8c7","container.image.repository":"docker.io/library/nginx",
"container.image.tag":"latest","container.name":"nginx","evt.time":1695903119619762538,
"k8s.ns.name":"default","k8s.pod.name":"nginx-app-5c64488cdf-dnjm7",
"proc.cmdline":"ls","user.name":"root"}}

On peut retrouver notre alerte sur slack:

Présentation de Falco Sidekick UI

Falco fournit une interface graphique facilitant la lecture des événements et des notifications. Pour ce test, nous avons simplement exposé le service falco-falcosidekick-ui en tant que service de type LoadBalancer pour pouvoir y accéder depuis notre navigateur.

Nous pouvons constater que la règle detect_ls_command a bien été affichée avec la priorité WARNING que nous avons spécifiée dans le fichier custom-rule.yaml.

Conclusion

En conclusion, notre exploration actuelle n’a fait qu’effleurer la surface des immenses possibilités et intégrations offertes par Falco. Cet outil offre une panoplie de fonctionnalités pour la surveillance et la sécurisation de vos environnements Kubernetes, et son potentiel va bien au-delà de ce que nous avons vu jusqu’à présent. Dans les prochains articles, nous plongerons plus profondément dans les capacités de Falco, explorant davantage ses fonctionnalités avancées, ses options de configuration et d’intégration, ainsi que les meilleures pratiques pour l’utiliser efficacement dans divers scénarios. Restez à l’écoute pour en apprendre davantage sur la puissance et la flexibilité que Falco peut apporter à votre infrastructure de conteneurs !