Unité 5.2 : Automatisation de la sécurité

Introduction

Vous avez déployé TaskBoard sur Managed Kubernetes dans le module 3, et il communique désormais avec PostgreSQL, Redis, Object Storage et Kafka. Chacune de ces connexions est protégée par un identifiant, et à l'heure actuelle, ces identifiants sont dispersés dans des fichiers de jetons, l'état Terraform et les magasins de secrets CI. Dès qu'un jeton fuit ou qu'un ingénieur quitte l'équipe, vous devez effectuer une rotation rapide, et ce sans avoir à effectuer manuellement une série de clics dans une console.

Cette unité aborde la sécurité sous forme de code. Vous automatiserez le cycle de vie complet des jetons à l'aide du Token Manager, gérerez les utilisateurs et l'accès avec le modèle IAM d'IONOS CLOUD dans Terraform, pousserez les règles de pare-feu via le même pipeline qui provisionne vos serveurs, et intégrerez les identifiants de base de données dans les secrets Kubernetes directement à partir des sorties Terraform. Le modèle d'accès d'IONOS CLOUD présente des particularités spécifiques : une autorisation basée sur les groupes plutôt que des politiques granulaires, des NSGs qui ne se lient pas aux équilibreurs de charge gérés ou aux nœuds Kubernetes, et des jetons affichés exactement une seule fois. Maîtriser ces particularités fait la différence entre une plateforme conforme aux audits et une incident à 2 h du matin.

1. Automatisation du cycle de vie des jetons API

Les jetons Bearer sont le moyen par lequel chaque appel API, chaque client SDK et chaque pipeline CI s'authentifie auprès d'IONOS CLOUD. Les traiter comme des secrets à longue durée de vie collés dans les fichiers de configuration constitue l'erreur de sécurité la plus courante sur la plateforme. Le Token Manager vous permet de générer des jetons par service avec des durées de vie limitées et de les faire tourner de manière programmatique.

Un jeton est demandé à l'aide de vos identifiants de contrat et est renvoyé au format JWT. La méthode d'authentification de base (nom d'utilisateur et mot de passe à chaque requête) est en cours de suppression et ne doit pas être utilisée dans l'automatisation. Il convient donc d'utiliser les jetons Bearer de manière uniforme partout.

1.1 Génération et périmètre des jetons

Demandez un jeton à l'aide de l'API d'authentification. La valeur token renvoyée est un JWT que vous passez ensuite en tant que Authorization: Bearer <token> lors des appels ultérieurs à l'API Cloud.

# Request a bearer token using contract credentials (one-time, e.g. in a bootstrap step)
curl -s --request GET \
  --user "$IONOS_USERNAME:$IONOS_PASSWORD" \
  'https://api.ionos.com/auth/v1/tokens/generate' \
  | jq -r '.token' > taskboard-ci.token

Chaque jeton comporte une durée de vie (TTL) qui détermine la période pendant laquelle il reste valide avant d'expirer et de devenir inactif. Les valeurs de TTL disponibles sont fixes : 1 heure, 4 heures, 1 jour, 7 jours, 30 jours, 60 jours, 90 jours, 180 jours et 365 jours. Choisissez la durée de vie la plus courte qu'un consommateur donné peut tolérer. Un pipeline CI exécuté à chaque fusion peut fonctionner avec un jeton de 7 jours renouvelé chaque semaine ; un contrôleur à longue exécution peut nécessiter 30 jours.

Un utilisateur unique peut détenir jusqu'à 100 jetons simultanément. Cette limite est suffisamment généreuse pour attribuer un jeton distinct à chaque service et à chaque environnement, ce qui est exactement ce que vous souhaitez : un jeton par service et par environnement, afin que la révocation d'une fuite de credential ne perturbe jamais aucun autre élément.

1.2 Rotation sans interruption de service

La valeur du jeton est affichée exactement une fois lors de sa génération et ne peut pas être récupérée par la suite. Il n'existe aucune opération « afficher le jeton à nouveau », votre logique de rotation doit donc capturer la valeur au moment de la création et l'écrire directement à sa destination (un secret CI, un secret Kubernetes) dans la même étape.

La rotation suit un modèle de génération puis de révocation, afin qu'il n'y ait jamais de période pendant laquelle aucun jeton valide n'existe.

#!/usr/bin/env bash
set -euo pipefail

# 1. Generate the new token and capture it immediately (only chance to read it)
NEW_TOKEN=$(curl -s --request GET --user "$IONOS_USERNAME:$IONOS_PASSWORD" \
  'https://api.ionos.com/auth/v1/tokens/generate' | jq -r '.token')

# 2. Push it to consumers BEFORE revoking the old one (overlap window)
kubectl create secret generic ionos-api-token \
  --from-literal=token="$NEW_TOKEN" \
  --namespace taskboard --dry-run=client -o yaml | kubectl apply -f -

# 3. List existing tokens, identify the old one by its jti, then delete it
curl -s --request GET --header "Authorization: Bearer $NEW_TOKEN" \
  'https://api.ionos.com/auth/v1/tokens' | jq '.tokens[] | {id: .id, expirationDate}'

La suppression d'un jeton dans Token Manager le désactive immédiatement, même si sa durée de vie (TTL) n'a pas encore expiré, de sorte que l'ancienne authentification est invalide dès l'instant où vous appelez DELETE. Exécutez ce script selon un calendrier (une tâche cron CI ou un CronJob Kubernetes) et la rotation devient une propriété de la plateforme plutôt qu'une tâche que quelqu'un se souvient d'effectuer.

2. IAM as Code

L'accès des utilisateurs et des groupes sur IONOS CLOUD suit un modèle de contrôle d'accès basé sur les rôles (Role-Based Access Control), construit autour des groupes et non de documents de politique par ressource. Vous attribuez des privilèges à un groupe, vous ajoutez des utilisateurs à ce groupe, et vous partagez des ressources spécifiques avec le groupe. Il n'existe pas de langage de politique granulaire par action ; modélisez donc votre conception d'accès autour des groupes dès le départ.

La gestion de cette configuration avec Terraform permet de rendre votre carte d'accès révisable dans les demandes d'extraction (pull requests) et reproductible entre les contrats.

2.1 Utilisateurs, groupes et privilèges

Un groupe porte un ensemble de privilèges au niveau du contrat. Les privilèges de groupe disponibles constituent un catalogue fixe : Create Data Center, Create Snapshots, Reserve IP Blocks, Create Internet Access, Use Object Storage, Create Backup Units, Create Kubernetes Clusters, et Access Activity Log. Vous activez uniquement les privilèges dont le groupe a besoin, et rien d'autre.

resource "ionoscloud_group" "taskboard_deployers" {
  name                  = "taskboard-deployers"
  create_datacenter     = false
  create_snapshot       = false
  reserve_ip            = false
  access_activity_log   = true
  create_k8s_cluster    = true
  s3_privilege          = true # Use Object Storage
  user_ids              = [ionoscloud_user.ci_bot.id]
}

resource "ionoscloud_user" "ci_bot" {
  first_name     = "TaskBoard"
  last_name      = "CI"
  email          = "ci-bot@taskboard.example"
  password       = var.ci_bot_password # sensitive, from a secret store
  administrator  = false
  force_sec_auth = false
}

Conservez administrator = false pour chaque utilisateur d'automatisation. Un administrateur contourne entièrement les privilèges de groupe, ce qui contredit le modèle du moindre privilège que vous êtes en train de mettre en place.

2.2 Partage de ressources avec des groupes

Les privilèges contrôlent ce qu'un groupe peut créer. Le partage de ressources contrôle ce qu'un groupe peut voir et sur quoi il peut agir pour les ressources qui existent déjà. Les types de ressources contrôlables sont les centres de données virtuels, les Snapshots, les images, les blocs IP, les unités de sauvegarde et les clusters Kubernetes. Pour chaque ressource partagée, un groupe reçoit un niveau d'autorisation : Lecture (implicite dès qu'une ressource est attribuée au groupe), Modification et Partage.

resource "ionoscloud_share" "taskboard_vdc_share" {
  group_id      = ionoscloud_group.taskboard_deployers.id
  resource_id   = ionoscloud_datacenter.taskboard.id
  edit_privilege  = true
  share_privilege = false
}

Le tableau suivant associe les trois niveaux d'autorisation aux actions qu'un membre du groupe peut effectuer, ce qui constitue la décision à prendre à chaque partage :

Accordez Sharing avec parcimonie. Un groupe pouvant repartager des ressources peut élargir l'accès au-delà de ce que votre Terraform décrit, créant ainsi un écart entre votre code et la réalité.

3. Automatisation des NSG dans le pipeline

Les Network Security Groups sont des pare-feu à état appliqués au niveau de la VM ou de la carte réseau. La gestion de leurs règles dans Terraform, plutôt que par modification manuelle, signifie que votre posture réseau est intégrée au même pipeline que les serveurs qu'elle protège et est examinée à chaque modification.

Par défaut, un NSG est configuré en refus de tout : le trafic est bloqué à moins qu'une règle ne l'autorise explicitement. Les règles prennent en charge les directions INGRESS et EGRESS ainsi qu'un large ensemble de protocoles, notamment TCP, UDP, ICMP, ICMPv6, GRE, VRRP, ESP et AH.

3.1 Les règles en tant que code

Associez un NSG à un serveur (couvrant toutes ses cartes réseau) ou à une carte réseau individuelle pour un contrôle granulaire, puis définissez les règles. La plateforme limite à 100 règles par NSG, 10 NSG par carte réseau et 200 NSG par VDC, ce qui est suffisamment généreux pour que vous rencontriez un problème de conception avant d'atteindre un quota.

resource "ionoscloud_nsg" "taskboard_app" {
  name          = "taskboard-app-tier"
  description   = "App tier: allow HTTPS in, Postgres out"
  datacenter_id = ionoscloud_datacenter.taskboard.id
}

resource "ionoscloud_nsg_firewallrule" "allow_https_in" {
  nsg_id          = ionoscloud_nsg.taskboard_app.id
  protocol        = "TCP"
  name            = "https-ingress"
  type            = "INGRESS"
  port_range_start = 443
  port_range_end   = 443
}

resource "ionoscloud_nsg_firewallrule" "allow_pg_out" {
  nsg_id          = ionoscloud_nsg.taskboard_app.id
  protocol        = "TCP"
  name            = "postgres-egress"
  type            = "EGRESS"
  port_range_start = 5432
  port_range_end   = 5432
}

# Bind the NSG to the app server's NIC
resource "ionoscloud_nic" "app_nic" {
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  server_id         = ionoscloud_server.app.id
  lan               = ionoscloud_lan.app_lan.id
  security_groups_ids = [ionoscloud_nsg.taskboard_app.id]
}

La ressource API sous-jacente est security-group, et chaque règle expose des propriétés telles que name, protocol, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpType et icmpCode. Les champs ICMP ne s'appliquent que lorsque le protocole est ICMP ou ICMPv6.

3.2 Ce que les NSG ne couvrent pas

C'est la contrainte qui coûte des heures de débogage aux développeurs. Les NSG s'appliquent uniquement au niveau des cartes réseau des serveurs VDC. Ils ne sont PAS liés au Managed Application Load Balancer, au Managed Network Load Balancer ou au Managed Kubernetes. Plus précisément, les nœuds des pools de nœuds du Managed Kubernetes et les Cubes en veille sont exclus de l'application des NSG.

# WRONG: there is no security_groups argument on a managed load balancer.
# resource "ionoscloud_application_loadbalancer" "alb" {
#   security_groups_ids = [ionoscloud_nsg.x.id]  # not a valid argument
# }

Pour un service placé derrière un ALB, comme l'API de TaskBoard, vous ne pouvez pas appliquer de pare-feu à l'ALB lui-même à l'aide d'un NSG. Protégez la couche en plaçant les serveurs d'application sur un LAN privé et en appliquant des règles NSG à leurs interfaces réseau, afin que seul le sous-réseau de l'ALB puisse y accéder. Pour Kubernetes, appliquez la politique de trafic à l'aide d'objets Kubernetes NetworkPolicy à l'intérieur du cluster, car les interfaces réseau des nœuds sont hors du périmètre des NSG. Les NSG sont également indépendants du pare-feu par interface réseau hérité ; ne vous attendez donc pas à ce que l'un hérite des règles de l'autre.

4. Secrets Kubernetes depuis Terraform

Les pods de TaskBoard ont besoin de la chaîne de connexion PostgreSQL, du mot de passe Redis et de la clé d'accès Object Storage. Aucune de ces valeurs ne doit jamais apparaître dans un manifeste soumis. Le modèle propre consiste à les récupérer depuis les sorties Terraform (marquées sensibles) et à créer des secrets Kubernetes à partir de ces sorties au moment du déploiement.

4.1 Sorties sensibles alimentant les secrets

Marquez chaque sortie de credential sensitive = true afin que Terraform ne l'affiche jamais dans les journaux ou dans terraform output sans le drapeau explicite.

output "pg_connection_uri" {
  value     = "postgresql://${ionoscloud_pg_cluster.taskboard.credentials[0].username}:${var.pg_password}@${ionoscloud_pg_cluster.taskboard.dns_name}:5432/taskboard?sslmode=require"
  sensitive = true
}

output "s3_access_key" {
  value     = ionoscloud_s3_key.taskboard.id
  sensitive = true
}

output "s3_secret_key" {
  value     = ionoscloud_s3_key.taskboard.secret_key
  sensitive = true
}

Au moment du déploiement, lisez ces sorties et créez le secret Kubernetes en une seule étape afin que la valeur en clair ne soit jamais enregistrée sur le disque dans un manifeste :

kubectl create secret generic taskboard-db \
  --namespace taskboard \
  --from-literal=DATABASE_URL="$(terraform output -raw pg_connection_uri)" \
  --from-literal=S3_ACCESS_KEY="$(terraform output -raw s3_access_key)" \
  --from-literal=S3_SECRET_KEY="$(terraform output -raw s3_secret_key)" \
  --dry-run=client -o yaml | kubectl apply -f -

L'idiome --dry-run=client -o yaml | kubectl apply -f - rend l'opération idempotente : sa réexécution met à jour le secret sur place au lieu d'échouer parce qu'il existe déjà.

4.2 Consommation et rotation des secrets

Le déploiement référence le secret par son nom, de sorte que la rotation d'un identifiant d'accès consiste à recréer le secret et à redémarrer les pods, et non à modifier un manifeste.

spec:
  containers:
    - name: taskboard-api
      image: taskboard-prod.cr.de-fra.ionos.com/taskboard/api:abc123
      envFrom:
        - secretRef:
            name: taskboard-db

Après avoir effectué la rotation de l'identifiant sous-jacent et réappliqué le secret, forcez les pods à le prendre en compte :

kubectl rollout restart deployment/taskboard-api -n taskboard

Pour les flottes de plus grande taille, un opérateur de secrets externe peut synchroniser les données depuis un magasin central selon un planning, mais le motif Terraform-output-to-secret constitue la base appropriée et permet de conserver la source de vérité des identifiants dans votre code d'infrastructure.

5. Automatisation des clés SSH

Les serveurs provisionnés par Terraform obtiennent leur accès SSH à partir de clés injectées au démarrage. Le SSH Key Manager stocke les clés par utilisateur (jusqu'à 100 clés enregistrées par utilisateur), ce qui permet à une équipe de référencer le même ensemble de clés au cours des déploiements, et cloud-init les injecte dans les nouvelles instances.

5.1 Injection et rotation des clés

Enregistrez les clés publiques de l'équipe et injectez-les via le cloud-init user_data du serveur. L'injection ad hoc de clés au moment de la provision est prise en charge via l'API Cloud, ce que Terraform utilise exactement.

locals {
  team_keys = [
    file("${path.module}/keys/alice.pub"),
    file("${path.module}/keys/bob.pub"),
  ]
}

resource "ionoscloud_server" "app" {
  name              = "taskboard-app"
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  cores             = 4
  ram               = 8192
  ssh_key_path      = local.team_keys

  volume {
    name      = "app-boot"
    size      = 20
    disk_type = "SSD"
    image_name = "ubuntu:latest"
  }
}

La rotation d'une clé d'équipe est une modification de code : supprimez l'ancienne .pub, ajoutez la nouvelle, puis terraform apply. Les nouveaux serveurs et les serveurs reconfigurés prennent en compte la modification immédiatement. Associez cette opération à une étape cloud-init qui supprime les clés obsolètes de ~/.ssh/authorized_keys sur les hôtes existants, afin que la rotation atteigne également les serveurs en cours d'exécution.

#cloud-config
ssh_authorized_keys:
  - ssh-ed25519 AAAA... alice@taskboard
  - ssh-ed25519 AAAA... bob@taskboard

Gardez les clés privées hors de l'état Terraform et hors de Git en totalité. Seules les clés publiques doivent se trouver dans votre dépôt ; les clés privées correspondantes restent avec chaque ingénieur ou dans un coffre de secrets dédié.

Fiche de référence rapide de l'API

Principales fins de point pour l'automatisation des jetons et de l'accès :

URL de base : https://api.ionos.com (Ressources de l'API Cloud sous /cloudapi/v6) Authentification : Authorization: Bearer <token>

Atelier de code

Objectif : Faire pivoter le jeton API de TaskBoard via le Token Manager, ajouter une règle NSG via Terraform et connecter une identifiante de base de données à un secret Kubernetes à partir d'une sortie Terraform.

Prérequis :

• Compte IONOS CLOUD avec des identifiants de contrat et un VDC TaskBoard existant
• Terraform avec le fournisseur ionoscloud configuré
• kubectl connecté à votre cluster MKS TaskBoard, jq installé

Étape 1 : Générer un nouveau jeton

NEW_TOKEN=$(curl -s --request GET --user "$IONOS_USERNAME:$IONOS_PASSWORD" \
  'https://api.ionos.com/auth/v1/tokens/generate' | jq -r '.token')
echo "${NEW_TOKEN:0:12}..."

Sortie attendue :

eyJ0eXAiOiJK...

Étape 2 : Lister vos jetons actifs

curl -s --request GET --header "Authorization: Bearer $NEW_TOKEN" \
  'https://api.ionos.com/auth/v1/tokens' | jq '.tokens | length'

Sortie attendue :

3

Étape 3 : Ajouter une règle d'entrée NSG dans Terraform

resource "ionoscloud_nsg_firewallrule" "lab_https" {
  nsg_id           = ionoscloud_nsg.taskboard_app.id
  protocol         = "TCP"
  name             = "lab-https"
  type             = "INGRESS"
  port_range_start = 443
  port_range_end   = 443
}

terraform apply -target=ionoscloud_nsg_firewallrule.lab_https

Sortie attendue :

ionoscloud_nsg_firewallrule.lab_https: Creation complete
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Étape 4 : Créer le secret K8s à partir d'une sortie sensible

kubectl create secret generic taskboard-db -n taskboard \
  --from-literal=DATABASE_URL="$(terraform output -raw pg_connection_uri)" \
  --dry-run=client -o yaml | kubectl apply -f -

Sortie attendue :

secret/taskboard-db configured

Étape 5 : Vérifier le secret sans le divulguer

kubectl get secret taskboard-db -n taskboard -o jsonpath='{.data.DATABASE_URL}' | base64 -d | sed 's/:[^@]*@/:****@/'

Sortie attendue :

postgresql://taskboard:****@pg-xxxx.de-fra.ionos.com:5432/taskboard?sslmode=require

Étape 6 : Redémarrer les pods pour prendre en compte le secret renouvelé

kubectl rollout restart deployment/taskboard-api -n taskboard
kubectl rollout status deployment/taskboard-api -n taskboard

Sortie attendue :

deployment "taskboard-api" successfully rolled out

Étape 7 : Révoquer l'ancien jeton

curl -s --request DELETE --header "Authorization: Bearer $NEW_TOKEN" \
  "https://api.ionos.com/auth/v1/tokens/$OLD_TOKEN_ID" -o /dev/null -w "%{http_code}\n"

Sortie attendue :

200

Liste de contrôle de validation :

• [ ] Un nouveau jeton a été généré et l'ancien jeton renvoie 401 après suppression
• [ ] La règle NSG est visible via terraform state show ionoscloud_nsg_firewallrule.lab_https
• [ ] Les Pods fonctionnent avec le secret tourné, aucune information d'identification dans aucun manifeste

Nettoyage :

terraform destroy -target=ionoscloud_nsg_firewallrule.lab_https
kubectl delete secret taskboard-db -n taskboard

Erreurs courantes

1. Tentative de lecture de la valeur d'un jeton une seconde fois

   • Problème : Votre script de rotation génère un jeton, consigne « rotated » dans le journal, puis tente plus tard de récupérer la valeur du jeton pour l'envoyer ailleurs, mais ne reçoit que des métadonnées.
   • Cause : La valeur du jeton est affichée exactement une fois lors de sa génération et ne peut pas être récupérée ultérieurement. La liste des jetons renvoie les identifiants et les dates d'expiration, jamais le secret.
   • Solution : Capturez la valeur lors de la création et écrivez-la à sa destination dans la même étape :

   NEW_TOKEN=$(curl -s --request GET --user "$U:$P" \
     'https://api.ionos.com/auth/v1/tokens/generate' | jq -r '.token')
   kubectl create secret generic ionos-api-token --from-literal=token="$NEW_TOKEN" \
     --dry-run=client -o yaml | kubectl apply -f -
   

2. Attache d'un NSG à un équilibreur de charge géré ou à un pool de nœuds Managed Kubernetes

   • Problème : Vous ajoutez security_groups_ids à un ALB ou vous vous attendez à ce que les règles NSG filtrent le trafic des nœuds Kubernetes, et rien n'est appliqué.
   • Cause : Les NSG s'appliquent uniquement au niveau des cartes réseau des serveurs VDC. Les ALB/NLB gérés sont hors périmètre, et les nœuds des pools de nœuds Managed Kubernetes sont explicitement exclus de l'application des NSG.
   • Correction : Appliquez les règles NSG aux cartes réseau des serveurs d'application situés derrière l'équilibreur de charge, et utilisez des objets NetworkPolicy de Kubernetes au sein du cluster pour le contrôle du trafic au niveau des pods.

3. Engagement d'identifiants parce que la sortie n'était pas marquée comme sensible

   • Problème : Un collègue exécute terraform output dans les journaux CI et le mot de passe de la base de données est affiché en texte brut dans la sortie de compilation.
   • Cause : Une sortie sans sensitive = true est rendue dans la sortie de la console et les journaux.
   • Correction : Marquez chaque sortie d'identifiants comme sensible et lisez-la explicitement avec -raw uniquement au point d'utilisation :

   output "pg_connection_uri" {
     value     = local.pg_uri
     sensitive = true
   }
   

Résumé

Vous pouvez désormais traiter la sécurité comme une partie de votre pipeline d'infrastructure plutôt que comme une tâche manuelle à effectuer dans la console. Les jetons sont générés avec des durées de validité limitées, limités par service et par environnement, et renouvelés selon une séquence de génération, de transmission et de révocation qui ne laisse jamais de lacune. L'accès est décrit sous forme de code à l'aide de groupes, d'utilisateurs et de partages, ce qui correspond au modèle RBAC basé sur les groupes d'IONOS CLOUD. Les règles de pare-feu sont livrées avec les serveurs qu'elles protègent, et les identifiants proviennent des sorties sensibles de Terraform et sont transmis directement aux secrets Kubernetes sans jamais toucher un fichier soumis au dépôt.

Les spécificités d'IONOS CLOUD sont ce qui permet de maintenir cette approche propre : les jetons affichés exactement une seule fois, un catalogue fixe de privilèges de groupe au lieu de politiques libres, et des NSG qui s'arrêtent au niveau de la carte réseau du serveur et n'atteignent jamais les équilibreurs de charge gérés ni les nœuds Kubernetes. Construisez votre plateforme autour de ces limites et elle restera auditable et récupérable.

Points clés :

• Générez un jeton bearer par service et par environnement (jusqu'à 100 par utilisateur) avec la durée de validité la plus courte fonctionnelle parmi l'ensemble fixe (1 heure à 365 jours)
• Les valeurs des jetons sont affichées exactement une seule fois et la suppression d'un jeton le désactive immédiatement, de sorte que la séquence de rotation sûre est : capturer, puis transmettre, puis révoquer
• L'accès à IONOS CLOUD repose sur un RBAC basé sur les groupes : attribuez des privilèges aux groupes, partagez les ressources aux niveaux Lecture/Modification/Partage, et maintenez les utilisateurs d'automatisation en tant que non administrateurs
• Les NSG sont étatiques, appliquent un refus par défaut, ne s'appliquent qu'au niveau de la carte réseau du serveur et ne couvrent PAS les équilibreurs de charge ALB/NLB gérés ni les nœuds Managed Kubernetes
• Saisissez les secrets Kubernetes à partir des sorties Terraform sensitive afin que les identifiants ne soient jamais stockés dans un manifeste ou dans Git

Terminologie importante :

• Token Manager : La fonctionnalité d'IONOS CLOUD qui génère, liste et révoque les jetons bearer (JWT) utilisés pour l'authentification via l'API et le SDK.
• TTL (Time To Live) : La période de validité fixe attribuée à un jeton lors de sa création, après laquelle il expire et devient inactif.
• RBAC basé sur les groupes : Le modèle d'accès d'IONOS CLOUD dans lequel les privilèges et les partages de ressources sont accordés aux groupes plutôt qu'aux utilisateurs individuels ou à des politiques par action.
• Network Security Group (NSG) : Un pare-feu étatique, avec refus par défaut, attaché au niveau de la VM ou de la carte réseau, géré via la ressource API security-group.
• Sortie sensible : Une sortie Terraform marquée sensitive = true afin que sa valeur soit exclue de la sortie de la console et des journaux.

Prochaines étapes

Continuer l'apprentissage : Unité 5.3 : GitOps et opérations de déploiement

Sujets connexes :

• Unité 2.3 : Équilibrage de charge et sécurité en tant que code
• Unité 5.1 : Observabilité et débogage