Unidad 5.2: Automatización de la seguridad

Introducción

Usted envió TaskBoard a Managed Kubernetes en el Módulo 3, y ahora se comunica con PostgreSQL, Redis, Object Storage y Kafka. Cada una de esas conexiones está protegida por una credencial, y en este momento esas credenciales están dispersas en archivos de tokens, estado de Terraform y almacenes de secretos de CI. En el momento en que un token se filtra o un ingeniero abandona el equipo, usted necesita rotar rápidamente y necesita hacerlo sin un clic manual en una consola.

Esta unidad trata la seguridad como código. Usted automatizará el ciclo de vida completo de los tokens a través de Token Manager, gestionará usuarios y acceso con el modelo de acceso de IONOS IAM en Terraform, empujará reglas de Firewall a través de la misma canalización que aprovisiona sus servidores, y conectará credenciales de base de datos a secretos de Kubernetes directamente desde las salidas de Terraform. El modelo de acceso de IONOS tiene aristas específicas, autorización basada en grupos en lugar de políticas granulares, NSGs que no se vinculan a equilibradores de carga administrados o nodos de Kubernetes, y tokens que se muestran exactamente una vez, y obtener esas aristas correctas es la diferencia entre una plataforma limpia de auditoría y un incidente a las 2 a.m.

1. API Automatización del ciclo de vida del token

Los tokens Bearer son la forma en que cada llamada a API, cliente SDK y tubería de CI se autentica en IONOS Cloud. Tratarlos como secretos de larga duración pegados en la configuración es el error de seguridad más común en la plataforma. El Token Manager le permite generar tokens por servicio con tiempos de vida limitados y rotarlos de forma programática.

Un token se solicita contra las credenciales de su contrato y se devuelve como un JWT. El método de autenticación básica (nombre de usuario y contraseña en cada solicitud) se está discontinuando y no debe usarse en la automatización, por lo que estandarice los tokens Bearer en todas partes.

1.1 Generación y alcance de tokens

Solicite un token utilizando el autenticador API. El valor devuelto token es un JWT que luego se pasa como Authorization: Bearer <token> en llamadas posteriores a Cloud API.

# 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

Cada token lleva un Tiempo de Vida (TTL) que fija cuánto tiempo es válido antes de expirar y volverse inactivo. Los valores de TTL disponibles son fijos: 1 Hora, 4 Horas, 1 Día, 7 Días, 30 Días, 60 Días, 90 Días, 180 Días y 365 Días. Elija el TTL más corto que un consumidor determinado pueda tolerar. Una tubería de CI que se ejecuta en cada combinación puede vivir con un token de 7 Días que se rota semanalmente; un controlador de larga duración puede necesitar 30 Días.

Un solo usuario puede tener hasta 100 tokens al mismo tiempo. Ese techo es lo suficientemente generoso como para dar a cada servicio y cada entorno su propio token, que es exactamente lo que usted quiere: un token por servicio, por entorno, para que revocar una credencial filtrada nunca detenga nada más.

1.2 Rotación sin tiempo de inactividad

El valor del token se muestra exactamente una vez en la generación y no se puede recuperar después. No hay una llamada "mostrar token de nuevo", por lo que su lógica de rotación debe capturar el valor en el momento de la creación y escribirlo directamente en su destino (un secreto de CI, un secreto de Kubernetes) en el mismo paso.

La rotación sigue un patrón de generar-y-revocar para que nunca haya un vacío donde no exista un token válido.

#!/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}'

Eliminar un token en el Token Manager lo desactiva inmediatamente, incluso si su TTL no ha expirado aún, por lo que la credencial antigua está muerta en el momento en que usted llama DELETE. Ejecute este script en un programa (un trabajo de cron de CI o un CronJob de Kubernetes) y la rotación se convierte en una propiedad de la plataforma en lugar de una tarea que alguien recuerda hacer.

2. IAM como código

El acceso de usuarios y grupos en IONOS Cloud sigue un modelo de Control de Acceso Basado en Roles construido sobre grupos, no en documentos de políticas por recurso. Usted asigna privilegios a un grupo, agrega usuarios al grupo y comparte recursos específicos con el grupo. No hay un lenguaje de política por acción, por lo que debe modelar su diseño de acceso alrededor de grupos desde el principio.

Administrar esto en Terraform mantiene su mapa de acceso revisable en solicitudes de extracción y reproducible en contratos.

2.1 Usuarios, grupos y privilegios

Un grupo lleva un conjunto de privilegios a nivel de contrato. Los privilegios de grupo disponibles son un catálogo fijo: Crear Centro de Datos, Crear Instantáneas, Reservar Bloques IP, Crear Acceso a Internet, Usar Object Storage, Crear Unidades de Copia de Seguridad, Crear Clusters Kubernetes y Acceder al Registro de Actividades. Usted habilita los privilegios que un grupo necesita y nada más.

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
}

Mantenga administrator = false para cada usuario de automatización. Un administrador omite los privilegios de grupo por completo, lo que derrota el modelo de privilegios mínimos que está construyendo.

2.2 Compartir recursos con grupos

Los privilegios controlan qué puede crear un grupo. El control de recursos compartidos controla qué puede ver y actuar un grupo sobre recursos que ya existen. Los tipos de recursos controlables son Centros de Datos Virtuales, Instantáneas, Imágenes, Bloques IP, Unidades de Copia de Seguridad y Clusters Kubernetes. Para cada recurso compartido, un grupo recibe un nivel de autorización: Leer (implícito tan pronto como el grupo se asigna un recurso), Editar y Compartir.

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
}

La siguiente tabla asigna los tres niveles de autorización a lo que puede hacer un miembro del grupo, que es la decisión que usted toma en cada compartición:

Otorgue Sharing con parsimonia. Un grupo que puede volver a compartir recursos puede ampliar el acceso más allá de lo que su Terraform describe, creando una divergencia entre su código y la realidad.

3. Automatización de NSG en la canalización

Los Network Security Groups son firewalls con estado aplicados en el nivel de VM o NIC. Administrar sus reglas en Terraform, en lugar de editarlas manualmente, significa que su postura de red vive en la misma canalización que los servidores que protege y se revisa en cada cambio.

Un NSG predetermina denegar todo: el tráfico se descarta a menos que una regla lo permita explícitamente. Las reglas admiten tanto direcciones INGRESS como EGRESS y un amplio conjunto de protocolos que incluye TCP, UDP, ICMP, ICMPv6, GRE, VRRP, ESP y AH.

3.1 Reglas como código

Adjunte un NSG a un servidor (que cubre todos sus NIC) o a un NIC individual para un control granular, luego defina reglas. La plataforma le limita a 100 reglas por NSG, 10 NSG por NIC y 200 NSG por VDC, lo que es lo suficientemente generoso como para que usted encuentre un problema de diseño antes de llegar al límite.

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]
}

El recurso subyacente API es security-group, y cada regla expone propiedades como name, protocol, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpType y icmpCode. Los campos ICMP solo se aplican cuando el protocolo es ICMP o ICMPv6.

3.2 Lo que los NSG no cubren

Esta es la restricción que le cuesta a los desarrolladores horas de depuración. Los NSG se aplican solo en el nivel de servidor-NIC de VDC. NO se unen a Managed Application Load Balancer, Managed Network Load Balancer o Managed Kubernetes. En particular, los nodos de grupo de Node y los Cubes suspendidos están excluidos de la aplicación de 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
# }

Para un servicio con ALB como TaskBoard's API, usted no puede Firewall el ALB en sí con un NSG. Proteja el nivel poniendo los servidores de aplicaciones en una red privada LAN y aplicando reglas de NSG a sus NIC para que solo la subred del ALB pueda alcanzarlos. Para Kubernetes, haga cumplir la política de tráfico con objetos de NetworkPolicy de Kubernetes dentro de Cluster, porque las NIC de Node están fuera del alcance de NSG. Los NSG también son independientes de la configuración de seguridad legacy por NIC Firewall, así que no espere que uno herede las reglas del otro.

4. Kubernetes Secretos desde Terraform

La tarea de TaskBoard necesita la cadena de conexión PostgreSQL, la contraseña Redis y la clave de acceso Object Storage. Ninguno de esos valores debería aparecer nunca en un manifiesto comprometido. El patrón limpio es obtenerlos desde las salidas (marcadas como sensibles) de Terraform y crear secretos Kubernetes a partir de esas salidas en el momento de la implementación.

4.1 Salidas sensibles que alimentan secretos

Marque cada salida de credenciales sensitive = true para que Terraform nunca la imprima en los registros o en terraform output sin la bandera explícita.

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
}

En el momento de la implementación, lea esas salidas y cree el Kubernetes secreto en un paso para que el valor sin formato nunca se almacene en disco en un manifiesto:

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 -

El idiom --dry-run=client -o yaml | kubectl apply -f - hace que la operación sea idempotente: volver a ejecutarla actualiza el secreto en su lugar en lugar de fallar porque ya existe.

4.2 Consumir y rotar secretos

La implementación hace referencia al secreto por nombre, por lo que rotar una credencial significa recrear el secreto y reiniciar el Pods, nunca editando un manifiesto.

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

Después de rotar las credenciales subyacentes y reaplicar el secreto, fuerce al Pods a recogerlo:

kubectl rollout restart deployment/taskboard-api -n taskboard

Para flotas más grandes, un operador de secretos externo puede sincronizar desde una tienda central según un calendario, pero el patrón de Terraform-salida-a-secreto es la línea de base correcta y mantiene la fuente de la verdad de la credencial en su código de infraestructura.

5. SSH Automatización clave

Los servidores aprovisionados por Terraform obtienen su acceso SSH a partir de claves inyectadas en el arranque. El SSH Key Manager almacena claves por usuario (hasta 100 claves guardadas por usuario) para que un equipo pueda hacer referencia al mismo conjunto de claves en todos los despliegues, y cloud-init las inyecta en nuevas instancias.

5.1 Inyectando y rotando claves

Almacene las claves públicas del equipo y injéctelas a través de cloud-init del servidor user_data. La inyección de claves ad-hoc en el momento de aprovisionamiento es compatible con Cloud API, que es exactamente lo que utiliza Terraform.

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"
  }
}

Rotar una clave de equipo es un cambio de código: elimine la clave antigua .pub, agregue la nueva y terraform apply. Los servidores nuevos y reaprovisionados recogen el cambio de inmediato. Combine esto con un paso cloud-init que elimine las claves obsoletas de ~/.ssh/authorized_keys en hosts existentes para que la rotación alcance también a los servidores en ejecución.

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

Mantenga las claves privadas fuera del estado de Terraform y fuera de Git por completo. Solo las claves públicas pertenecen a su repositorio; las claves privadas correspondientes permanecen con cada ingeniero o en una tienda de secretos dedicada.

API Tarjeta de referencia rápida

Puntos de conexión clave para la automatización de tokens y acceso:

URL base: https://api.ionos.com (Recursos de Cloud API bajo /cloudapi/v6) Autenticación: Authorization: Bearer <token>

Laboratorio de código

Objetivo: Rotar el token de TaskBoard's API a través de Token Manager, agregar una regla de NSG a través de Terraform y conectar una credencial de base de datos a un secreto de Kubernetes desde una salida de Terraform.

Requisitos previos:

• Cuenta de IONOS Cloud con credenciales de contrato y un TaskBoard VDC existente
• Terraform con el proveedor ionoscloud configurado
• kubectl conectado a su TaskBoard MKS Cluster, jq instalado

Paso 1: Generar un token fresco

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}..."

Salida esperada:

eyJ0eXAiOiJK...

Paso 2: Listar sus tokens activos

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

Salida esperada:

3

Paso 3: Agregar una regla de ingreso de NSG en 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

Salida esperada:

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

Paso 4: Crear el secreto de K8s a partir de una salida 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 -

Salida esperada:

secret/taskboard-db configured

Paso 5: Verificar el secreto sin revelarlo

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

Salida esperada:

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

Paso 6: Reiniciar Pods para recoger el secreto rotado

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

Salida esperada:

deployment "taskboard-api" successfully rolled out

Paso 7: Revocar el token antiguo

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"

Salida esperada:

200

Lista de verificación:

• [ ] Nuevo token generado y token antiguo devuelve 401 después de la eliminación
• [ ] Regla de NSG visible a través de terraform state show ionoscloud_nsg_firewallrule.lab_https
• [ ] Pods en ejecución con el secreto rotado, sin credenciales en ningún manifiesto

Limpieza:

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

Errores comunes

1. Intentar leer un valor de token por segunda vez

   • Problema: Su script de rotación genera un token, registra "rotado", y luego intenta recuperar el valor del token para enviarlo a algún lugar y solo obtiene metadatos.
   • Por qué sucede: El valor del token se muestra exactamente una vez durante la generación y no se puede recuperar. La lista de tokens devuelve IDs y caducidad, pero nunca el secreto.
   • Solución: Capture el valor en el momento de la creación y escríbalo en su destino en el mismo paso:

   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. Adjuntar un NSG a un grupo de Load Balancer administrado o un grupo de nodos de MKS Node

   • Problema: Agrega security_groups_ids a un ALB o espera que las reglas de NSG filtren el tráfico de Kubernetes Node, y nada se aplica.
   • Por qué sucede: Los NSG se aplican solo en el nivel de servidor-NIC del VDC. Los ALB/NLB administrados están fuera de alcance, y los nodos del grupo de Managed Kubernetes Node están explícitamente excluidos de la aplicación de NSG.
   • Solución: Aplicar reglas de NSG a las NIC de los servidores de aplicaciones detrás del Load Balancer, y usar objetos de NetworkPolicy de Kubernetes dentro del Cluster para el control de tráfico a nivel de pod.

3. Comprometer credenciales porque la salida no se marcó como sensible

   • Problema: Un compañero de equipo ejecuta terraform output en los registros de CI y la contraseña de la base de datos se imprime en texto plano en la salida de la compilación.
   • Por qué sucede: Una salida sin sensitive = true se renderiza en la salida de la consola y los registros.
   • Solución: Marcar cada salida de credenciales como sensible y leerla explícitamente con -raw solo en el punto de uso:

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

Resumen

Ahora puede tratar la seguridad como parte de su tubería de infraestructura en lugar de una tarea manual de consola. Los tokens se generan con TTL limitados, con alcance por servicio y por entorno, y se rotan con una secuencia de generar-pushear-revocar que nunca deja un vacío. El acceso se describe como código a través de grupos, usuarios y recursos compartidos, coincidiendo con el modelo de grupo basado en RBAC de IONOS. Las reglas de Firewall se envían junto con los servidores que protegen, y las credenciales fluyen desde salidas sensibles de Terraform directamente a secretos de Kubernetes sin tocar nunca un archivo comprometido.

Los bordes específicos de IONOS son lo que mantiene esto limpio: los tokens se muestran exactamente una vez, un catálogo fijo de privilegios de grupo en lugar de políticas de forma libre, y NSGs que se detienen en el nivel de NIC del servidor y nunca alcanzan los equilibradores de carga administrados o los nodos de Kubernetes. Construya alrededor de esos bordes y su plataforma permanece auditada y recuperable.

Puntos clave:

• Genere un token de portador por servicio por entorno (hasta 100 por usuario) con el TTL más corto posible del conjunto fijo (1 hora a 365 días)
• Los valores de los tokens se muestran exactamente una vez y eliminar un token lo desactiva inmediatamente, por lo que la orden de rotación segura es capturar-entonces-pushear-entonces-revocar
• El acceso de IONOS es basado en grupos RBAC: asigne privilegios a grupos, comparta recursos en niveles de Lectura/Edición/Compartir, mantenga a los usuarios de automatización como no administradores
• Las NSGs son estado, denegación por defecto, se aplican solo en el nivel de NIC del servidor y NO cubren los nodos de Managed ALB/NLB o Managed Kubernetes
• Fuente de secretos de Kubernetes desde sensitive salidas de Terraform para que las credenciales nunca vivan en un manifiesto o Git

Terminología importante:

• Token Manager: La característica de IONOS que genera, enumera y revoca tokens de portador (JWT) utilizados para la autenticación de API y SDK.
• TTL (Tiempo de vida): El período de validez fijo asignado a un token en su creación, después del cual expira y se vuelve inactivo.
• Grupo basado en RBAC: El modelo de acceso de IONOS donde los privilegios y los recursos compartidos se otorgan a grupos en lugar de a usuarios individuales o políticas por acción.
• Grupo de seguridad de red (NSG): Un Firewall estado, denegación por defecto, adjunto al nivel de VM o NIC, administrado a través del recurso de security-group API.
• Salida sensible: Una salida de Terraform marcada sensitive = true para que su valor se excluya de la salida de consola y los registros.

Próximos pasos

Continúe aprendiendo: Unidad 5.3: GitOps y operaciones de implementación

Temas relacionados:

• Unidad 2.3: Equilibrio de carga y seguridad como código
• Unidad 5.1: Observabilidad y depuración