Проблеми автентифікації AWS EKS при використанні різних користувачів для Terraform Plan та Apply

8 Березня 2024 в 21:54 24

Використання різних ролей IAM AWS для фаз плану та виконання в Terraform у CI/CD конвеєрі – це загально прийнята практика для забезпечення чіткого розділення привілеїв. Проте, при роботі з AWS EKS (Elastic Kubernetes Service), такий підхід може викликати проблеми автентифікації.

Сценарій передбачає використання ролі IAM AWS з правами тільки на читання для фази планування Terraform та більш привілейованої ролі з правами на читання та запис для фази виконання. Хоча ця стратегія покращує безпеку та розділення обов’язків, вона може призвести до проблем з автентифікацією з EKS.

Під час фази планування Terraform створює дані автентифікації для EKS, використовуючи роль з правами тільки на читання. Оскільки ця роль не має дозволу на доступ до EKS, розгортання ресурсів, таких як Helm charts, не вдається під час фази виконання.

Одним з можливих рішень є надання ролі з правами тільки на читання необхідних дозволів для EKS. Однак такий підхід може поставити під загрозу розділення привілеїв.

Іншим аспектом є питання, чи відповідає такий підхід виконанню Terraform під час CI/CD конвеєра. Хоча це загально прийнята практика для обмеження обсягу дозволів для операцій планування, в цьому контексті вона може не відповідати вимогам автентифікації EKS.

Альтернативною можливістю є дослідження способів забезпечення того, щоб фаза виконання використовувала правильні облікові дані для читання та запису без порушення моделі безпеки. Це може включати налаштування конфігурації механізму автентифікації, який використовує Terraform для взаємодії з EKS.

## Отримання посилання на дані кластера Kube
"aws_eks_cluster" "cluster" {
  name = var.cluster_name
}
## Отримання даних автентифікації
data "aws_eks_cluster_auth" "cluster" {
  name = var.cluster_name
}
## Використання даних автентифікації
провайдер "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.cluster.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
    token                  = data.aws_eks_cluster_auth.cluster.token
  }
}

## Отримання посилання на дані кластера Kube

"aws_eks_cluster" "cluster" {

name = var.cluster_name

}

## Отримання даних автентифікації

data "aws_eks_cluster_auth" "cluster" {

name = var.cluster_name

}

## Використання даних автентифікації

провайдер "helm" {

kubernetes {

host = data.aws_eks_cluster.cluster.endpoint

cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)

token = data.aws_eks_cluster_auth.cluster.token

}

Повідомлення про помилку від Terraform показує, що кластер Kubernetes недосяжний, тому що клієнтові потрібні облікові дані. Це підкреслює важливість забезпечення того, що відповідні ролі IAM мають необхідні дозволи для взаємодії з EKS.

На завершення, хоча використання різних ролей IAM для фаз планування та виконання покращує безпеку та розділення обов’язків, важливо вирішити проблеми з автентифікацією, особливо при роботі з такими сервісами, як AWS EKS. Знаходження правильного балансу між безпекою та вимогами експлуатації є важливим для створення ефективного робочого процесу CI/CD.