Unité 5.2 : Automatisation de la sécurité

Introduction

Vous avez expédié TaskBoard vers Managed Kubernetes à l'unité 3, et il communique maintenant avec PostgreSQL, Redis, Object Storage, et Kafka. Chacune de ces connexions est protégée par une information d'identification, et actuellement, ces informations d'identification sont dispersées dans des fichiers de jeton, l'état de Terraform, et les magasins de secrets CI. Dès qu'un jeton est divulgué ou qu'un ingénieur quitte l'équipe, vous devez le remplacer rapidement et vous devez le faire sans avoir à cliquer manuellement dans une console.

Cette unité traite la sécurité comme du code. Vous allez automatiser le cycle de vie complet des jetons via le Token Manager, gérer les utilisateurs et les accès avec le modèle IONOS IAM dans Terraform, pousser les règles de pare-feu via le même pipeline qui provisionne vos serveurs, et connecter les informations d'identification de la base de données aux secrets Kubernetes directement à partir des sorties de Terraform. Le modèle d'accès IONOS a des caractéristiques spécifiques, une autorisation basée sur les groupes plutôt que des politiques fines, des groupes de sécurité réseau (NSGs) qui ne sont pas liés aux équilibreurs de charge gérés ou aux nœuds Kubernetes, et des jetons qui sont affichés exactement une fois, et obtenir ces caractéristiques correctes fait la différence entre une plateforme propre aux audits et un incident à 2 heures du matin.

1. API Automatisation du cycle de vie des jetons

Les jetons porteurs sont la façon dont chaque appel API, chaque client SDK et chaque pipeline CI s'authentifie sur IONOS Cloud. Les traiter comme des secrets à longue durée de vie collés dans une configuration est 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é contre vos informations d'identification de contrat et est renvoyé sous la forme d'un JWT. La méthode d'authentification de base (nom d'utilisateur et mot de passe pour chaque demande) est en cours de suppression et ne devrait pas être utilisée dans l'automatisation, donc standardisez les jetons porteurs partout.

1.1 Génération et étendue des jetons

Demandez un jeton en utilisant l'authentification API. La valeur token renvoyée est un JWT que vous passez ensuite en tant que Authorization: Bearer <token> sur les appels Cloud API suivants.

# 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 fixe la durée pendant laquelle il est valide avant d'expirer et de devenir inactif. Les valeurs 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 TTL la plus courte qu'un consommateur donné peut tolérer. Un pipeline CI qui s'exécute à chaque fusion peut vivre avec un jeton de 7 jours tourné hebdomadairement ; un contrôleur à longue durée de vie peut avoir besoin de 30 jours.

Un seul utilisateur peut détenir jusqu'à 100 jetons à la fois. Ce plafond est suffisamment généreux pour donner à chaque service et à chaque environnement son propre jeton, ce qui est exactement ce que vous voulez : un jeton par service, par environnement, afin que la révocation d'une information d'identification compromise ne fasse jamais tomber autre chose.

1.2 Rotation sans temps d'arrêt

La valeur du jeton est affichée exactement une fois à la génération et n'est pas récupérable par la suite. Il n'y a pas d'appel « afficher à nouveau le jeton », donc votre logique de rotation doit 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, de sorte qu'il n'y a jamais d'intervalle où 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 le Token Manager le désactive immédiatement, même si sa durée de vie n'a pas encore expiré, donc l'ancienne information d'identification est morte dès que vous appelez DELETE. Exécutez ce script sur un calendrier (un travail cron CI ou un travail Kubernetes CronJob) et la rotation devient une propriété de la plateforme plutôt qu'une tâche que quelqu'un se souvient de faire.

2. IAM en tant que code

L'accès utilisateur et de groupe sur IONOS Cloud suit un modèle de contrôle d'accès basé sur les rôles construit sur des groupes, et non sur des documents de stratégie par ressource. Vous attribuez des privilèges à un groupe, ajoutez des utilisateurs au groupe et partagez des ressources spécifiques avec le groupe. Il n'y a pas de langage de stratégie par action, fine et précise, donc concevez votre modèle d'accès autour des groupes dès le départ.

La gestion de cela dans Terraform permet de garder votre carte d'accès examinable dans les demandes de tirage et reproductible à travers les contrats.

2.1 Utilisateurs, groupes et privilèges

Un groupe possède un ensemble de privilèges au niveau du contrat. Les privilèges de groupe disponibles sont un catalogue fixe : Créer un centre de données, Créer des instantanés, Réserver des blocs IP, Créer un accès Internet, Utiliser Object Storage, Créer des unités de sauvegarde, Créer des grappes Kubernetes, et Accéder au journal d'activité. Vous activez les privilèges dont un groupe a besoin et rien de plus.

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
}

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
}

resource "ionoscloud_group_user" "ci_bot_membership" {
  group_id = ionoscloud_group.taskboard_deployers.id
  user_id  = ionoscloud_user.ci_bot.id
}

Gardez administrator = false pour chaque utilisateur d'automatisation. Un administrateur contourne complètement les privilèges de groupe, ce qui annule le modèle de privilèges minimum que vous êtes en train de créer.

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 agir sur les ressources qui existent déjà. Les types de ressources contrôlables sont les centres de données virtuels, les instantanés, les images, les blocs IP, les unités de sauvegarde et les grappes Kubernetes. Pour chaque ressource partagée, un groupe reçoit un niveau d'autorisation : Lecture (implicite dès que le groupe est affecté à une ressource), Édition 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 mappe les trois niveaux d'autorisation à ce qu'un membre du groupe peut faire, ce qui est la décision que vous prenez pour chaque partage :

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

3. Automatisation des NSG dans le pipeline

Les Network Security Groups sont des pare-feus à état appliqués au niveau VM ou NIC. La gestion de leurs règles dans Terraform, plutôt que de les modifier manuellement, signifie que votre posture réseau vit dans le même pipeline que les serveurs qu'il protège et est examinée à chaque modification.

Un NSG est par défaut défini sur refuser-tout : le trafic est rejeté à 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 Règles en tant que code

Attachez un NSG à un serveur (couvrant tous ses NIC) ou à un NIC individuel pour un contrôle granulaire, puis définissez des règles. La plateforme vous limite à 100 règles par NSG, 10 NSG par NIC et 200 NSG par VDC, ce qui est suffisamment généreux pour que vous rencontriez un problème de conception avant de rencontrer une limite de 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 sous-jacente API 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

Ceci est la contrainte qui coûte aux développeurs des heures de débogage. Les NSG s'appliquent uniquement au niveau VDC serveur-NIC. Ils ne sont PAS liés à Managed Application Load Balancer, Managed Network Load Balancer, ou Managed Kubernetes. Plus précisément, les nœuds de pool Node et les Cubes suspendus 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 avec ALB comme TaskBoard's API, vous ne pouvez pas mettre un pare-feu sur l'ALB lui-même avec un NSG. Protégez le niveau en plaçant les serveurs d'application sur un réseau privé LAN et en appliquant des règles NSG à leurs NIC, de sorte que seul le sous-réseau ALB puisse les atteindre. Pour Kubernetes, appliquez la politique de trafic avec des objets NetworkPolicy Kubernetes à l'intérieur de Cluster, car les NIC Node sont en dehors de la portée des NSG. Les NSG sont également indépendants du pare-feu legacy par NIC, donc ne vous attendez pas à ce que l'un hérite des règles de l'autre.

4. Kubernetes Secrets from Terraform

La tâche TaskBoard nécessite la chaîne de connexion PostgreSQL, le mot de passe Redis, et la clé d'accès Object Storage. Aucune de ces valeurs ne devrait jamais apparaître dans un manifeste validé. Le modèle propre consiste à les extraire à partir des 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 crédential sensitive = true afin que Terraform ne l'imprime jamais dans les journaux ou dans terraform output sans le flag 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
}

À la mise en production, lisez ces sorties et créez le Kubernetes secret en une seule étape afin que la valeur en clair ne soit jamais stockée sur 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 : réexécuter celle-ci met à jour le secret en place plutôt que de provoquer une erreur parce qu'il existe déjà.

4.2 Consommation et rotation des secrets

Le déploiement référence le secret par nom, donc la rotation d'un identifiant signifie recréer le secret et redémarrer le Pods, sans jamais modifier de 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 rotatif le justificatif sous-jacent et réappliqué le secret, forcez le Pods à le récupérer :

kubectl rollout restart deployment/taskboard-api -n taskboard

Pour les flottes plus importantes, un opérateur de secrets externe peut synchroniser à partir d'un magasin central selon un calendrier, mais le modèle Terraform-output-to-secret est la bonne référence de base et conserve la source de vérité des informations d'identification dans votre code d'infrastructure.

5. SSH Automatisation clé

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) afin qu'une équipe puisse référencer le même jeu de clés à travers les déploiements, et cloud-init les injecte dans les nouvelles instances.

5.1 Injection et rotation des clés

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

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, et terraform apply. Les nouveaux serveurs et les serveurs reprovisionnés adoptent le changement immédiatement. Associez cela à 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 en dehors de l'état Terraform et de Git entièrement. Seules les clés publiques appartiennent à votre référentiel ; les clés privées correspondantes restent avec chaque ingénieur ou dans un magasin de secrets dédié.

API Référence Quick Card

Points de terminaison clés pour l'automatisation des jetons et de l'accès :

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

Laboratoire de code

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

Prérequis :

• Compte IONOS Cloud avec des informations d'identification de contrat et un VDC TaskBoard existant
• Terraform avec le fournisseur ionoscloud configuré
• kubectl connecté à votre TaskBoard MKS Cluster, jq installé

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

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 le 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 le Pods pour prendre en compte le secret pivoté

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 validation :

• [ ] Nouveau jeton généré et l'ancien jeton retourne 401 après suppression
• [ ] Règle NSG visible via terraform state show ionoscloud_nsg_firewallrule.lab_https
• [ ] Pods en cours d'exécution avec le secret pivoté, aucune information d'identification dans aucun manifeste

Nettoyage :

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

Pièges courants

1. Essayer de lire une valeur de jeton pour la deuxième fois

   • Problème : Votre script de rotation génère un jeton, enregistre « rotated », puis tente plus tard de récupérer la valeur du jeton pour la transmettre quelque part et n'obtient que des métadonnées.
   • Pourquoi cela se produit-il : La valeur du jeton est affichée exactement une fois lors de la génération et n'est pas récupérable. La liste des jetons renvoie les ID et l'expiration, mais jamais le secret.
   • Correction : 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. Attacher un NSG à un Load Balancer géré ou à un pool MKS Node

   • Problème : Vous ajoutez security_groups_ids à un ALB ou vous attendez que les règles NSG filtrent le trafic Kubernetes Node, et rien n'est appliqué.
   • Pourquoi cela se produit-il : Les NSG s'appliquent uniquement au niveau du serveur NIC du centre de données virtuel. Les ALB/NLB gérés sont hors de portée, et les nœuds du pool Managed Kubernetes Node sont explicitement exclus de l'application des règles NSG.
   • Correction : Appliquez les règles NSG aux NIC des serveurs d'application derrière le Load Balancer, et utilisez les objets NetworkPolicy Kubernetes à l'intérieur du Cluster pour contrôler le trafic au niveau des pods.

3. Valider les informations d'identification parce que la sortie n'était pas marquée comme sensible

   • Problème : Un membre de l'équipe exécute terraform output dans les journaux CI et le mot de passe de la base de données est imprimé en clair dans la sortie de construction.
   • Pourquoi cela se produit-il : Une sortie sans sensitive = true est rendue dans la sortie de la console et les journaux.
   • Correction : Marquez chaque sortie d'informations d'identification 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 maintenant traiter la sécurité comme une partie de votre pipeline d'infrastructure plutôt que comme une tâche manuelle de console. Les jetons sont générés avec des TTL limités, étendus par service et par environnement, et tournés avec une séquence de génération-poussée-révocation qui ne laisse jamais d'interruption. L'accès est décrit comme du code à travers les groupes, les utilisateurs et les partages, correspondant au modèle de groupe basé sur RBAC d'IONOS. Les règles de pare-feu sont livrées avec les serveurs qu'elles protègent, et les informations d'identification proviennent de sorties Terraform sensibles directement dans les secrets Kubernetes sans jamais toucher un fichier validé.

Les bords spécifiques à IONOS sont ce qui maintient cela propre : les jetons affichés exactement une fois, un catalogue fixe de privilèges de groupe au lieu de politiques libres, et les 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 ou les nœuds Kubernetes. Construisez autour de ces bords et votre plateforme reste auditable et récupérable.

Points clés :

• Générez un jeton porteur par service par environnement (jusqu'à 100 par utilisateur) avec le TTL le plus court possible de l'ensemble fixe (1 heure à 365 jours)
• Les valeurs des jetons sont affichées exactement une fois et la suppression d'un jeton le désactive immédiatement, donc la commande de rotation sécurisée est capture-then-push-then-revoke
• L'accès IONOS est basé sur des groupes RBAC : attribuez des privilèges aux groupes, partagez des ressources aux niveaux Lecture/Édition/Partage, gardez les utilisateurs d'automatisation non-administrateurs
• Les NSG sont des pare-feu d'état, par défaut tout refuser, s'appliquent uniquement au niveau de la carte réseau du serveur, et NE couvrent PAS les nœuds Managed ALB/NLB ou Managed Kubernetes
• Sourcez les secrets Kubernetes à partir des sorties sensitive Terraform afin que les informations d'identification ne soient jamais stockées dans un manifeste ou Git

Terminologie importante :

• Token Manager : La fonctionnalité IONOS qui génère, liste et révoque les jetons porteurs (JWT) utilisés pour l'authentification API et SDK.
• TTL (Temps de vie) : La période de validité fixe attribuée à un jeton lors de sa création, après laquelle il expire et devient inactif.
• Modèle d'accès basé sur des groupes RBAC : Le modèle d'accès IONOS où les privilèges et les partages de ressources sont accordés aux groupes plutôt qu'aux utilisateurs individuels ou aux politiques par action.
• Groupe de sécurité réseau (NSG) : Un pare-feu d'état, par défaut tout refuser, attaché au niveau de la carte réseau ou du serveur, géré via la ressource security-group API.
• Sortie sensible : Une sortie Terraform marquée sensitive = true afin que sa valeur soit exclue de la sortie de 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