kubernetes-sigs/aws-iam-authenticatorAWS IAM 자격 증명을 사용하여 Kubernetes 클러스터에 인증하는 도구
AWS IAM 자격 증명을 사용하여 Kubernetes 클러스터에 인증하는 도구입니다. 이 도구의 초기 작업은 Heptio가 주도했습니다. 이 프로젝트는 여러 커뮤니티 엔지니어의 기여를 받으며, 현재 Heptio와 Amazon EKS OSS 엔지니어가 유지 관리하고 있습니다.
AWS에서 Kubernetes 클러스터를 운영하는 관리자라면, 클러스터를 프로비저닝하고 업데이트하기 위해 이미 AWS IAM 자격 증명을 관리해야 합니다. Kubernetes용 AWS IAM Authenticator를 사용하면 Kubernetes 액세스를 위한 별도의 자격 증명을 관리할 필요가 없습니다. AWS IAM은 또한 CloudTrail을 통한 대역 외 감사 추적과 2FA/MFA 적용 등 여러 가지 유용한 속성을 제공합니다.
AWS에서 Kubernetes 설치 프로그램을 구축하는 경우, Kubernetes용 AWS IAM Authenticator는 부트스트랩 프로세스를 단순화할 수 있습니다.
새로 설치한 클러스터에서 초기 관리자 자격 증명을 어떻게든 안전하게 빼돌릴 필요가 없습니다.
대신 클러스터 프로비저닝 시점에 전용 KubernetesAdmin 역할을 생성하고, 클러스터 관리자 로그인을 허용하도록 Authenticator를 설정할 수 있습니다.
AWS에서 실행 중인 클러스터가 있고 Kubernetes용 AWS IAM Authenticator 지원을 추가하려면 다음을 수행해야 합니다:
먼저, Kubernetes 클러스터 내의 사용자/그룹에 매핑될 하나 이상의 IAM 역할을 생성해야 합니다. 가장 쉬운 방법은 AWS 콘솔에 로그인하는 것입니다:
이렇게 하면 계정의 권한이 부여된 사용자/역할이 수임할 수 있는 권한이 없는 IAM 역할이 생성됩니다. 아래에서 필요할 역할의 Amazon Resource Name(ARN)을 기록해 두세요.
AWS 콘솔 대신 AWS CLI를 사용하여 한 단계로 이 작업을 수행할 수도 있습니다:
# get your account ID
ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')
# define a role trust policy that opens the role to users in your account (limited by IAM policy)
POLICY=$(echo -n '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::'; echo -n "$ACCOUNT_ID"; echo -n ':root"},"Action":"sts:AssumeRole","Condition":{}}]}')
# create a role named KubernetesAdmin (will print the new role's ARN)
aws iam create-role \
--role-name KubernetesAdmin \
--description "Kubernetes administrator role (for AWS IAM Authenticator for Kubernetes)." \
--assume-role-policy-document "$POLICY" \
--output text \
--query 'Role.Arn'
이 단계를 건너뛰고 다음을 사용할 수도 있습니다:
mapUsers 참조).mapRoles 참조).이 서버는 각 마스터 노드에서 호스트 네트워킹을 사용하는 DaemonSet으로 실행되어 localhost 포트를 노출하도록 설계되었습니다.
ConfigMap 및 DaemonSet 구성 예시는 deploy/example.yaml을 참조하십시오.
적용하기 전에 클러스터에 맞게 다음 값을 업데이트하십시오:
config.yaml의 자리 표시자 IAM ARN(arn:aws:iam::000000000000:...)을 교체하십시오.clusterID를 클러스터에 고유한 값으로 설정하십시오.그런 다음 배포하십시오:
kubectl apply -f deploy/example.yaml
kubectl -n kube-system rollout status daemonset/aws-iam-authenticator
kubectl -n kube-system get pods -l k8s-app=aws-iam-authenticator
Pod가 컨트롤 플레인 노드에서 실행되면, aws-iam-authenticator server는 호스트의 /etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml(또는 --generate-kubeconfig로 구성된 경로)에 webhook kubeconfig를 생성합니다.
자동화된 설치 프로그램을 구축하는 경우, aws-iam-authenticator init을 사용하여 인증서, 키 및 webhook kubeconfig 파일을 손쉽게 사전 생성할 수도 있습니다.
이 명령은 파일을 생성하여 구성된 출력 디렉터리에 배치합니다.
API 서버를 시작하기 전에 각 마스터 노드에서 이를 실행할 수 있습니다. 마스터 노드를 프로비저닝하기 전에 생성하여 적절한 호스트 경로에 설치할 수도 있습니다.
파일을 사전 생성하지 않으면, aws-iam-authenticator server가 필요 시 파일을 생성합니다.
이는 작동하지만 설치 후 Kubernetes API 서버를 재시작해야 합니다.
Kubernetes API는 토큰 인증 webhook을 사용하여 AWS IAM Authenticator for Kubernetes와 통합됩니다.
aws-iam-authenticator server를 실행하면 webhook 구성 파일을 생성하여 호스트 파일 시스템에 저장합니다.
API 서버 구성에 단일 추가 플래그를 추가해야 합니다:
--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml
많은 클러스터에서 API 서버는 정적 파드로 실행됩니다.
/etc/kubernetes/manifests/kube-apiserver.yaml에 플래그를 추가할 수 있습니다.
호스트 디렉터리 /etc/kubernetes/aws-iam-authenticator/가 API 서버 파드에 마운트되어 있는지 확인하세요.
업데이트된 정적 파드 정의를 반영하려면 마스터 노드에서 kubelet 데몬을 재시작해야 할 수도 있습니다:
systemctl restart kubelet.service
서버의 기본 동작은 구성 파일의 mapUsers 및 mapRoles 필드에서만 매핑을 가져오는 것입니다. 자세한 내용은 아래의 전체 구성 형식을 참조하세요.
--backend-mode 플래그를 사용하면 서버가 두 가지 추가 백엔드에서 매핑을 가져오도록 구성할 수 있습니다: EKS 스타일 ConfigMap(--backend-mode=EKSConfigMap) 또는 IAMIdentityMapping 사용자 정의 리소스(--backend-mode=CRD)입니다. 서버 파드에 의해 마운트되는 서버 구성 파일인 기본 백엔드는 --backend-mode=MountedFile에 해당합니다.
이러한 백엔드의 쉼표로 구분된 목록을 전달하여 서버가 순서대로 검색하도록 할 수 있습니다. 예를 들어 --backend-mode=EKSConfigMap,MountedFile을 사용하면 서버는 먼저 EKS 스타일 ConfigMap에서 매핑을 검색한 다음, 주어진 IAM 역할/사용자에 대한 매핑을 찾지 못하면 서버 구성 파일에서 검색합니다. 동일한 IAM 역할/사용자에 대한 매핑이 여러 백엔드에 존재하는 경우, 서버는 쉼표로 구분된 목록에서 먼저 나오는 백엔드의 매핑을 사용합니다. 이 예에서 EKS ConfigMap에서 매핑이 발견되면 서버 구성 파일에 중복되거나 충돌하는 매핑이 존재하더라도 해당 매핑이 사용됩니다.
단일 백엔드를 설정할 때 서버는 오직 해당 백엔드에서만 매핑을 가져오며, 다른 백엔드가 존재하더라도 무시한다는 점에 유의하세요. 예를 들어 --backend-mode=CRD를 사용하면 서버는 오직 IAMIdentityMappings에서만 매핑을 가져오고 마운트된 파일과 EKS ConfigMap은 무시합니다.
MountedFile이것은 매핑의 기본 백엔드이며 대부분의 사용자에게 충분합니다. 자세한 내용은 아래의 전체 구성 형식을 참조하세요.
CRD (알파)이 백엔드는 각 IAM 매핑을 IAMIdentityMapping Kubernetes 사용자 정의 리소스로 모델링합니다. 이 접근 방식을 사용하면 kubectl 또는 API를 사용하여 Kubernetes 네이티브 방식으로 매핑을 유지 관리할 수 있습니다. 또한 구문 오류(예: 잘못 정렬된 YAML)를 더 쉽게 포착할 수 있으며 모든 매핑에 영향을 미치지 않습니다.
IAMIdentityMapping CRD를 설정하려면 먼저 CRD 매니페스트를 apply해야 합니다:
kubectl apply -f deploy/iamidentitymapping.yaml
CRD가 배포된 후에는 IAM ID를 모델링하는 사용자 정의 리소스를 생성할 수 있습니다. ./deploy/example-iamidentitymapping.yaml을 참조하세요:
---
apiVersion: iamauthenticator.k8s.aws/v1alpha1
kind: IAMIdentityMapping
metadata:
name: kubernetes-admin
spec:
# Arn of the User or Role to be allowed to authenticate
arn: arn:aws:iam::XXXXXXXXXXXX:user/KubernetesAdmin
# Username that Kubernetes will see the user as, this is useful for setting
# up allowed specific permissions for different users
username: kubernetes-admin
# Groups to be attached to your users/roles. For example `system:masters` to
# create cluster admin, or `system:nodes`, `system:bootstrappers` for nodes to
# access the API server.
groups:
- system:masters
EKSConfigMapEKS 스타일의 kube-system/aws-auth ConfigMap이 백엔드로 사용됩니다. 이
ConfigMap은 EKS 클러스터에서와 정확히 동일한 형식이어야 합니다:
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. 이는
EKS에서 마이그레이션하거나 EKS로 마이그레이션할 때 매핑을 유지하려는 경우, 또는
다른 AWS 클러스터와 함께 EKS를 운영하면서 각 클러스터에서 동일한
매핑을 유지하려는 경우에 유용합니다.
DynamicFilecfg.dynamicfilepath로 지정된 로컬 파일이 백엔드로 사용될 수 있습니다. 파일 내용은 EKSConfigMap과 정확히 동일한 형식이어야 합니다. 이 파일 내용이 변경될 때마다 authenticator가 자동으로 다시 로드합니다. 이는 ARN 매핑 관리에 더 많은 유연성을 제공합니다.
DynamicFile 모드를 구성하는 방법은 https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml 를 확인하세요.
DynamicFile 모드가 활성화된 kind 클러스터를 사용해 보려면 make e2e RUNNER=kind를 실행하세요.
aws-iam-authenticator는 k8s 사용자 이름에 대한 예약 접두사를 지원할 수 있습니다. 예약 접두사가 설정된 경우, 예약 접두사로 시작하는 사용자 이름은 "username must not begin with with the following prefixes:" 오류와 함께 인증되지 않습니다.