Cuatro pasos para reforzar la seguridad de Amazon EKS

Escrito por

Kamil Potrec

21 de julio de 2021

0 minutos de lectura

En la primera parte de esta serie de blogs, exploramos cómo implementar Amazon EKS con Terraform y analizamos cómo proteger la implementación inicial de RBAC y el Servicio de metadatos de instancias. En esta segunda publicación, veremos más prácticas recomendadas para reforzar la seguridad de Amazon EKS, incluida la importancia de usar roles de IAM dedicados para la entrega continua, una arquitectura multicuenta para aislar los clústeres de Amazon EKS y cifrar los secretos en el plano de control. Por último, mostraremos cómo incorporar herramientas de análisis estático en tus pipelines de CD para detectar estos problemas antes de que lleguen a los entornos de producción.

Lleva un registro de quién implementó el clúster

El servicio Amazon EKS se integra con el servicio de administración de identidades y acceso para autenticar a los usuarios en el clúster. Las decisiones de autorización se toman mediante el modelo nativo de RBAC de Kubernetes. La configuración de RBAC se asigna a las identidades de IAM a través de aws-auth ConfigMap. Sin embargo, existe una asignación especial que no aparece en ningún archivo de configuración ni ajuste. La entidad de IAM utilizada para crear el clúster se asigna automáticamente al grupo integrado de Kubernetes system:masters. Esto está bien documentado en la documentación para usuarios. Sin embargo, tiene implicaciones importantes para la auditabilidad de los permisos del clúster.

Para mostrar el impacto de esta configuración, eliminaremos todos los Roles y ClusterRoles de nuestro clúster de demostración.

1dev@pwnbox:~$ kubectl delete clusterroles --all
2clusterrole.rbac.authorization.k8s.io "admin" deleted
3clusterrole.rbac.authorization.k8s.io "aws-node" deleted
4clusterrole.rbac.authorization.k8s.io "cluster-admin" deleted
5clusterrole.rbac.authorization.k8s.io "edit" deleted
6clusterrole.rbac.authorization.k8s.io "eks:addon-manager" deleted
7clusterrole.rbac.authorization.k8s.io "eks:fargate-manager" deleted
8clusterrole.rbac.authorization.k8s.io "eks:node-bootstrapper" deleted
9clusterrole.rbac.authorization.k8s.io "eks:node-manager" deleted
10clusterrole.rbac.authorization.k8s.io "eks:podsecuritypolicy:privileged" deleted
11<OMITTED>
12dev@pwnbox:~$ kubectl delete roles --all-namespaces --all
13role.rbac.authorization.k8s.io "system:controller:bootstrap-signer" deleted
14role.rbac.authorization.k8s.io "eks:addon-manager" deleted
15role.rbac.authorization.k8s.io "eks:certificate-controller" deleted
16role.rbac.authorization.k8s.io "eks:fargate-manager" deleted
17role.rbac.authorization.k8s.io "eks:node-manager" deleted
18<OMITTED>
19dev@pwnbox:~$ kubectl auth can-i --list
20Resources                                       Non-Resource URLs   Resource Names   Verbs
21*.*                                               []                  []               [*]
22                                                [*]                 []               [*]
23selfsubjectaccessreviews.authorization.k8s.io   []                  []               [create]
24selfsubjectrulesreviews.authorization.k8s.io    []                  []               [create]
25                                                [/api/*]            []               [get]
26                                                [/api]              []               [get]
27                                                [/apis/*]           []               [get]
28                                                [/apis]             []               [get]
29                                                [/healthz]          []               [get]
30                                                [/healthz]          []               [get]
31                                                [/livez]            []               [get]
32                                                [/livez]            []               [get]
33                                                [/openapi/*]        []               [get]
34                                                [/openapi]          []               [get]
35                                                [/readyz]           []               [get]
36                                                [/readyz]           []               [get]
37                                                [/version/]         []               [get]
38                                                [/version/]         []               [get]
39                                                [/version]          []               [get]
40                                                [/version]          []               [get]
41dev@pwnbox:~$ kubectl get configmap --all-namespaces
42NAMESPACE     NAME                                 DATA   AGE
43kube-system   coredns                              1      7h59m
44kube-system   cp-vpc-resource-controller           0      7h58m
45kube-system   eks-certificates-controller          0      7h59m
46kube-system   extension-apiserver-authentication   6      7h59m
47kube-system   kube-proxy                           1      7h59m
48kube-system   kube-proxy-config                    1      7h59m

Amazon EKS usa autenticación de tokens mediante webhook para integrarse con IAM. Podemos ver la configuración en los argumentos del servidor de API.

1FLAG: --authentication-token-webhook-cache-ttl="7m0s"
2FLAG: --authentication-token-webhook-config-file="/etc/kubernetes/authenticator/apiserver-webhook-kubeconfig.yaml"
3FLAG: --authentication-token-webhook-version="v1beta1"
4

AWS IAM tiene el concepto de identificadores únicos, que se pueden usar en servicios específicos para evitar errores de configuración por reutilización de nombres. La documentación de Amazon EKS no aclara si el permiso system:masters está vinculado al identificador único de la entidad o a su nombre descriptivo. Para validar si eliminar la entidad original revoca todos los permisos del clúster, eliminamos el rol temporal y lo volvimos a crear.

1dev@pwnbox:~$ aws iam get-role --role-name ci-eks-test
2{
  "Role": {
      "Path": "/",
      "RoleName": "ci-eks-test",
      "RoleId": "AROAYREY3WYOOSHLPO3W6",
      "Arn": "arn:aws:iam::123456789012:role/ci-eks-test",
      "CreateDate": "2021-06-20T21:09:01+00:00",
      "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:iam::123456789012:user/ci"
                  },
                  "Action": "sts:AssumeRole",
                  "Condition": {}
              }
          ]
      },
      "MaxSessionDuration": 3600,
      "RoleLastUsed": {}
  }
25}
26dev@pwnbox:~$ kubectl auth can-i --list
27Resources                                       Non-Resource URLs   Resource Names     Verbs
28*.*                                             []                  []                 [*]
                                              [*]                 []                 [*]
30selfsubjectaccessreviews.authorization.k8s.io   []                  []                 [create]
31selfsubjectrulesreviews.authorization.k8s.io    []                  []                 [create]
                                              [/api/*]            []                 [get]
                                              [/api]              []                 [get]
                                              [/apis/*]           []                 [get]
                                              [/apis]             []                 [get]
                                              [/healthz]          []                 [get]
                                              [/healthz]          []                 [get]
                                              [/livez]            []                 [get]
                                              [/livez]            []                 [get]
                                              [/openapi/*]        []                 [get]
                                              [/openapi]          []                 [get]
                                              [/readyz]           []                 [get]
                                              [/readyz]           []                 [get]
                                              [/version/]         []                 [get]
                                              [/version/]         []                 [get]
                                              [/version]          []                 [get]
                                              [/version]          []                 [get]
48podsecuritypolicies.policy                      []                  [eks.privileged]   [use]
49
50dev@pwnbox:~$ aws iam get-role --role-name ci-eks-test
51{
  "Role": {
      "Path": "/",
      "RoleName": "ci-eks-test",
      "RoleId": "AROAYREY3WYOAK6QMGSUT",
      "Arn": "arn:aws:iam::123456789012:role/ci-eks-test",
      "CreateDate": "2021-06-20T21:14:28+00:00",
      "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:iam::123456789012:user/ci"
                  },
                  "Action": "sts:AssumeRole",
                  "Condition": {}
              }
          ]
      },
      "MaxSessionDuration": 3600,
      "RoleLastUsed": {}
  }
74}
75dev@pwnbox:~$ kubectl auth can-i --list
76Resources                                       Non-Resource URLs   Resource Names     Verbs
77*.*                                             []                  []                 [*]
                                              [*]                 []                 [*]
79selfsubjectaccessreviews.authorization.k8s.io   []                  []                 [create]
80selfsubjectrulesreviews.authorization.k8s.io    []                  []                 [create]
                                              [/api/*]            []                 [get]
                                              [/api]              []                 [get]
                                              [/apis/*]           []                 [get]
                                              [/apis]             []                 [get]
                                              [/healthz]          []                 [get]
                                              [/healthz]          []                 [get]
                                              [/livez]            []                 [get]
                                              [/livez]            []                 [get]
                                              [/openapi/*]        []                 [get]
                                              [/openapi]          []                 [get]
                                              [/readyz]           []                 [get]
                                              [/readyz]           []                 [get]
                                              [/version/]         []                 [get]
                                              [/version/]         []                 [get]
                                              [/version]          []                 [get]
                                              [/version]          []                 [get]
97podsecuritypolicies.policy                      []                  [eks.privileged]   [use]

Como puedes ver, tenemos un rol completamente nuevo, identificado por un RoleId diferente. Sin embargo, el servicio de autenticación de Amazon EKS usa el nombre descriptivo del rol para concedernos los mismos permisos de system:masters.

La forma más eficaz de mitigar este problema es usar un sistema de implementación centralizado, asignar un rol dedicado a las implementaciones y evitar a toda costa el uso de credenciales personales. Herramientas como aws-vault pueden ayudarte a administrar de forma segura el cambio entre distintos roles.

Ahora veamos cómo se autentican los nodos en el plano de control.

Usa la separación multicuenta para los clústeres

Amazon EKS requiere que todos los nodos tengan asociado un perfil de instancia con las siguientes dos políticas: AmazonEKSWorkerNodePolicy y AmazonEC2ContainerRegistryReadOnly.

1dev@pwnbox:$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy --version-id v1
2{
  "PolicyVersion": {
      "Document": {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Action": [
                      "ec2:DescribeInstances",
                      "ec2:DescribeRouteTables",
                      "ec2:DescribeSecurityGroups",
                      "ec2:DescribeSubnets",
                      "ec2:DescribeVolumes",
                      "ec2:DescribeVolumesModifications",
                      "ec2:DescribeVpcs",
                      "eks:DescribeCluster"
                  ],
                  "Resource": "*",
                  "Effect": "Allow"
              }
          ]
      },
      "VersionId": "v1",
      "IsDefaultVersion": true,
      "CreateDate": "2018-05-27T21:09:01+00:00"
  }
27}
28
29dev@pwnbox:$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly --version-id v3
30{
  "PolicyVersion": {
      "Document": {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "ecr:GetAuthorizationToken",
                      "ecr:BatchCheckLayerAvailability",
                      "ecr:GetDownloadUrlForLayer",
                      "ecr:GetRepositoryPolicy",
                      "ecr:DescribeRepositories",
                      "ecr:ListImages",
                      "ecr:DescribeImages",
                      "ecr:BatchGetImage",
                      "ecr:GetLifecyclePolicy",
                      "ecr:GetLifecyclePolicyPreview",
                      "ecr:ListTagsForResource",
                      "ecr:DescribeImageScanFindings"
                  ],
                  "Resource": "*"
              }
          ]
      },
      "VersionId": "v3",
      "IsDefaultVersion": true,
      "CreateDate": "2019-12-10T20:56:32+00:00"
  }
59}

De forma predeterminada, las políticas otorgan privilegios sobre todos los recursos de la cuenta de AWS. Esto significa que un pod comprometido en este clúster podrá enumerar información sobre cualquier recurso, VPC, subred e imagen de la cuenta.

El nodo de Amazon EKS también necesita acceso a otra política administrada llamada AmazonEKS_CNI_Policy. Esta política permite que el nodo asigne direcciones IP y realice cualquier función relacionada con la red.

1dev@pwnbox:$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy --version-id v4
2{
  "PolicyVersion": {
      "Document": {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "ec2:AssignPrivateIpAddresses",
                      "ec2:AttachNetworkInterface",
                      "ec2:CreateNetworkInterface",
                      "ec2:DeleteNetworkInterface",
                      "ec2:DescribeInstances",
                      "ec2:DescribeTags",
                      "ec2:DescribeNetworkInterfaces",
                      "ec2:DescribeInstanceTypes",
                      "ec2:DetachNetworkInterface",
                      "ec2:ModifyNetworkInterfaceAttribute",
                      "ec2:UnassignPrivateIpAddresses"
                  ],
                  "Resource": "*"
              },
              {
                  "Effect": "Allow",
                  "Action": [
                      "ec2:CreateTags"
                  ],
                  "Resource": [
                      "arn:aws:ec2:*:*:network-interface/*"
                  ]
              }
          ]
      },
      "VersionId": "v4",
      "IsDefaultVersion": true,
      "CreateDate": "2020-04-20T20:52:01+00:00"
  }
39}

Esta política permite que quien la invoca modifique la configuración de red de cualquier instancia de la cuenta. De hecho, Amazon recomienda asociar esta política directamente a la cuenta de servicio de Kubernetes aws-node. De forma predeterminada, el módulo de Terraform asocia esta política al perfil de IAM. Podemos cambiar este comportamiento si establecemos el atributo attach_worker_cni_policy en false.

Cifra tus secretos

Uno de los componentes del plano de control administrados por el servicio Amazon EKS es el almacén de clave-valor etcd. El servidor de API de Kubernetes lo usa para almacenar todos los objetos y las configuraciones. De forma predeterminada, Kubernetes no cifra los datos almacenados en este almacén de clave-valor. AWS es responsable de la seguridad de los componentes del plano de control; aun así, podemos aplicar una estrategia de defensa en profundidad para reforzar aún más la seguridad de nuestros datos.

El servicio AWS KMS es uno de los proveedores de cifrado que puede ofrecer cifrado de sobre para los objetos Secret almacenados en nuestro clúster. Si establecemos la opción `cluster_encryption_config`, podemos especificar una clave de KMS que se usará para cifrar las claves de cifrado de datos intermedias; estas, a su vez, se usarán para cifrar objetos específicos. Esta publicación del blog de Amazon EKS de AWS ofrece un excelente resumen del proceso subyacente. A partir de este momento, cualquier persona con acceso a un clúster de etcd no podrá leer nuestros secretos sin tener también acceso a nuestra clave de KMS. Todo el proceso es completamente transparente para el usuario final.

Detecta problemas en el pipeline de implementación

La infraestructura como código nos permite describir de forma declarativa el estado deseado del clúster de Amazon EKS. Así, podemos detectar estáticamente algunos de estos problemas antes de implementar cualquier recurso.

En Terraform podemos generar un plan de la configuración que se implementará.

1dev@pwnbox:$ terraform plan
2
3Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
<= read (data resources)
6
7Terraform will perform the following actions:
8
# data.aws_eks_cluster.cluster will be read during apply
# (config refers to values not yet known)
<= data "aws_eks_cluster" "cluster"  {
    + arn                       = (known after apply)
    + certificate_authority     = (known after apply)
    + created_at                = (known after apply)
    + enabled_cluster_log_types = (known after apply)
    + endpoint                  = (known after apply)
    + id                        = (known after apply)
    + identity                  = (known after apply)
    + kubernetes_network_config = (known after apply)
    + name                      = (known after apply)
    + platform_version          = (known after apply)
    + role_arn                  = (known after apply)
    + status                    = (known after apply)
    + tags                      = (known after apply)
    + version                   = (known after apply)
    + vpc_config                = (known after apply)
  }
28
29<OMITTED>
30
31# module.vpc.aws_vpc.this[0] will be created
+ resource "aws_vpc" "this" {
    + arn                              = (known after apply)
    + assign_generated_ipv6_cidr_block = false
    + cidr_block                       = "10.0.0.0/16"
    + default_network_acl_id           = (known after apply)
    + default_route_table_id           = (known after apply)
    + default_security_group_id        = (known after apply)
    + dhcp_options_id                  = (known after apply)
    + enable_classiclink               = (known after apply)
    + enable_classiclink_dns_support   = (known after apply)
    + enable_dns_hostnames             = false
    + enable_dns_support               = true
    + id                               = (known after apply)
    + instance_tenancy                 = "default"
    + ipv6_association_id              = (known after apply)
    + ipv6_cidr_block                  = (known after apply)
    + main_route_table_id              = (known after apply)
    + owner_id                         = (known after apply)
    + tags                             = {
        + "Name" = "eks-threat-modelling-ddddaaaa"
      }
    + tags_all                         = {
        + "Name" = "eks-threat-modelling-ddddaaaa"
      }
  }
57
58Plan: 44 to add, 0 to change, 0 to destroy.
59
60Changes to Outputs:
+ cluster_endpoint          = (known after apply)
+ cluster_name              = (known after apply)
+ cluster_security_group_id = (known after apply)
+ config_map_aws_auth       = []
+ kubectl_config            = (known after apply)
+ region                    = "eu-west-1

Este plan se puede convertir al formato JSON, lo que nos permite realizar un análisis estático de todos los atributos.

1dev@pwnbox:$ terraform show -json tfplan > tfplan.json
2dev@pwnbox:$ jq '.resource_changes[] | select((.type == "aws_eks_cluster") and .mode == "managed").change.after' tfplan.json
3{
"enabled_cluster_log_types": [
  "audit",
  "authenticator"
],
"encryption_config": [
  {
    "provider": [
      {}
    ],
    "resources": [
      "secrets"
    ]
  }
],
"kubernetes_network_config": [
  {}
],
"name": "eks-threat-modelling-ddddaaaa",
"tags": null,
"timeouts": {
  "create": "30m",
  "delete": "15m",
  "update": null
},
"version": "1.19",
"vpc_config": [
  {
    "endpoint_private_access": true,
    "endpoint_public_access": false,
    "public_access_cidrs": [
      "0.0.0.0/0"
    ]
  }
]
38}

Una vez que entendemos la estructura del plan de Terraform, podemos usar Open Policy Agent y su lenguaje declarativo para escribir pruebas sencillas.

1package play
2
3deny[msg]{
4    input.vpc_config[0].endpoint_public_access == true
5    msg := sprintf("The public endpoint is enabled on the cluster", [])
6}

Puedes probar este sencillo ejemplo en Rego Playground, una herramienta en línea.

Escribir estas reglas puede volverse engorroso. Requiere analizar las estructuras de salida de Terraform, procesar los archivos, mantener las bibliotecas y presentar los resultados de forma clara. Aquí es donde pueden ayudar productos como Snyk IaC. Este es un ejemplo del análisis de seguridad que se realiza en nuestra implementación predeterminada.

1dev@pwnbox:$ snyk iac test tfplan.json
2
3Testing tfplan.json...
4
5Infrastructure as code issues:
6  ✗ EKS cluster allows public access [High Severity] [SNYK-CC-TF-94] in EKS
7    introduced by aws_eks_cluster[this] > vpc_config
8
9  ✗ Non-Encrypted root block device [Medium Severity] [SNYK-CC-TF-53] in EC2
10    introduced by aws_launch_configuration[workers] > root_block_device > encrypted
11
12  ✗ Public IPs are automatically mapped to instances [Low Severity] [SNYK-CC-AWS-427] in VPC
13    introduced by aws_subnet[public_0] > map_public_ip_on_launch
14
15  ✗ EKS control plane logging insufficient [Low Severity] [SNYK-CC-TF-131] in EKS
16    introduced by aws_eks_cluster[this] > enabled_cluster_log_types
17
18  ✗ Public IPs are automatically mapped to instances [Low Severity] [SNYK-CC-AWS-427] in VPC
19    introduced by aws_subnet[public_2] > map_public_ip_on_launch
20
21  ✗ Public IPs are automatically mapped to instances [Low Severity] [SNYK-CC-AWS-427] in VPC
22    introduced by aws_subnet[public_1] > map_public_ip_on_launch
23
24Organization:      p0tr3c
25Type:              Terraform
26Target file:       tfplan.json
27Project name:      hardened
28Open source:       no
29Project path:      tfplan.json
30
31Tested tfplan.json for known issues, found 6 issues
32
33dev@pwnbox:/$

Con el análisis de IaC de Snyk, puedes detectar problemas en tu configuración de Terraform antes de implementarla en producción y mantener seguros tus entornos de producción. ¡Crea una cuenta gratis en https://app.snyk.io! Además, puedes probar la herramienta gratuita de revisión de código de Snyk para evaluar rápidamente la seguridad de tu código.

Protege la infraestructura desde el origen

Snyk automatiza la seguridad y el cumplimiento de IaC en los flujos de trabajo, y detecta recursos con desviaciones de configuración y recursos faltantes.

Agenda una demostración en vivo Comenzar gratis

Lleva un registro de quién implementó el clúster

Usa la separación multicuenta para los clústeres

Cifra tus secretos

Detecta problemas en el pipeline de implementación

Protege la infraestructura desde el origen

Leer más