인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!
IAM 조인을 사용하여 Kubernetes 클러스터 등록
이 가이드에서는 에이전트의 IAM ID를 사용하여 Teleport 클러스터에 Kubernetes 클러스터를 등록하는 방법을 보여줍니다.
Kubernetes 클러스터에 조인 비밀을 배포하지 않고도 등록하려는 각 클러스터에 Teleport Kubernetes 서비스를 배포하여 여러 Kubernetes 클러스터를 Teleport와 함께 등록할 수 있습니다.
Kubernetes 클러스터가 처음 등록되면, 에이전트는 Teleport ID를 Kubernetes 비밀에 저장합니다. 에이전트는 이후 재시작 시 이 ID를 사용하여 클러스터에 자동으로 조인합니다.
Proxy 서비스가 레이어 7 로드 밸런서 또는 리버스 프록시 뒤에 있는 클러스터에 조인하는 기능은 Teleport 13.0+에서 지원됩니다.
전제 조건
-
실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
-
tctl
관리자 도구와tsh
클라이언트 도구.tctl
및tsh
다운로드 방법에 대한 지침은 설치를 방문하십시오.
- Kubernetes 클러스터 버전 >= v1.17.0
- 클러스터에 대한 기존 IAM OpenID Connect (OIDC) 제공자
- Helm >= 3.4.2
- AWS CLI >=
2.10.3
또는1.27.81
Helm과 Kubernetes가 설치되어 있고 최신 상태인지 확인하십시오.
helm versionversion.BuildInfo{Version:"v3.4.2"}
kubectl versionClient Version: version.Info{Major:"1", Minor:"17+"}
Server Version: version.Info{Major:"1", Minor:"17+"}
- 연결이 가능한지 확인하기 위해
tsh login
으로 로그인한 다음, 현재 자격 증명을 사용하여tctl
명령어를 실행할 수 있는지 확인하십시오. 예를 들어:클러스터에 연결할 수 있고tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 17.0.0-dev
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status
명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속tctl
명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로tctl
명령어를 실행할 수도 있습니다.
1/3단계. IAM ID로 Kubernetes 서비스 계정 생성
Teleport는 AWS에서 실행되는 에이전트가 실행 중인 IAM ID를 사용하여 클러스터에 조인할 수 있는 모드를 지원합니다. 이를 통해 Kubernetes 클러스터에 조인 비밀을 배포하지 않고도 AWS에서 실행되는 Kubernetes 클러스터를 등록할 수 있습니다.
EKS 노드의 ID에 의존하지 않고 클러스터에 안전하게 조인하기 위해 Teleport 에이전트는 연결된 IAM 역할과 함께 별도의 Kubernetes 서비스 계정으로 실행해야 합니다. 노드 ID에 의존하는 것은 권장되지 않으며, IAM 역할이 서비스 계정에 대해 구성되지 않은 경우 모든 노드에서 실행 중인 포드는 노드 ID에 접근할 수 있어 쉽게 위험에 처할 수 있습니다.
IRSA가 올바르게 작동하려면 Kubernetes 클러스터에 IAM 역할을 Kubernetes 서비스 계정에 매핑하는 IAM OpenID Connect가 필요합니다.
Kubernetes 서비스 계정은 sts:GetCallerIdentity
API에 접근할 수 있어야 하며, 다른 권한은 필요하지 않습니다.
IAM 정책을 만들기 위해서는 다음 명령을 실행하십시오:
cat >iam-policy.json <<EOF{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:GetCallerIdentity", "Resource": "*" } ]}EOF
그 다음 IAM 정책을 생성합니다:
aws iam create-policy --policy-name kube-iam-policy --policy-document file://iam-policy.json{ "Policy": { "PolicyName": "kube-iam-policy", "PolicyId": "ANPAW2Y2Q2Y2Y2Y2Y2Y2Y", "Arn": "arn:aws:iam::aws:policy/kube-iam-policy", "Path": "/", "DefaultVersionId": "v1", "AttachmentCount": 0, "PermissionsBoundaryUsageCount": 0, "IsAttachable": true, "Description": "", "CreateDate": "2021-03-18T15:12:00+00:00", "UpdateDate": "2021-03-18T15:12:00+00:00" }}
이제 Kubernetes 서비스 계정을 생성하고 이를 IAM 역할에 매핑해야 합니다. 이는 두 가지 방법으로 수행할 수 있습니다. 클러스터가 eksctl
을 사용하여 프로비저닝된 경우 eksctl
을 사용할 수 있고, AWS CLI 방법을 사용할 수 있습니다.
eksctl
은 새로운 IAM 역할을 자동으로 생성하고 이를 대상 네임스페이스의 Kubernetes 서비스 계정에 매핑하는 것을 지원합니다.
eksctl create iamserviceaccount \ --name teleport-kube-agent-sa \ --namespace teleport-agent \ --cluster kube-cluster \ --region aws-region \ --attach-policy-arn arn:aws:iam::aws:policy/kube-iam-policy \ --role-name kube-iam-role \ --approve
참조된 매개변수는 다음과 같습니다:
- teleport-kube-agent-sa는 Kubernetes 서비스 계정의 이름입니다.
- teleport-agent는 Teleport Kubernetes 서비스가 실행 중인 네임스페이스입니다.
- aws-region는 클러스터가 실행 중인 AWS 리전입니다.
- kube-iam-policy는 이전 단계에서 생성된 IAM 정책의 이름입니다.
- kube-cluster 는 Kubernetes 클러스터의 이름입니다.
- kube-iam-role는 생성할 IAM 역할의 이름입니다.
명령이 완료되면 AWS 계정에 새로운 IAM 역할과 대상 네임스페이스에 새로운 Kubernetes 서비스 계정이 생성되었음을 확인할 수 있습니다.
대상 네임스페이스의 Kubernetes 서비스 계정에 새로운 IAM 역할을 생성하고 매핑하는 AWS CLI를 사용하는 방법은 몇 가지 추가 단계가 필요합니다.
먼저 Kubernetes 클러스터에 대상 네임스페이스와 Kubernetes 서비스 계정을 생성해야 합니다.
kubectl create ns teleport-agentnamespace/teleport-agent createdkubectl create sa teleport-kube-agent-sa -n teleport-agentserviceaccount/teleport-kube-agent-sa created
그 다음, IAM 역할과 신뢰 관계를 생성해야 합니다. 그를 위해 AWS 계정 ID와 OIDC 제공자 URL을 얻어야 합니다. 클러스터에 OIDC 제공자가 구성되어 있지 않다면 다음 가이드를 확인하십시오: IAM OpenID Connect (OIDC).
AWS 계정 ID를 추출하기 위해 다음 명령을 사용할 수 있습니다:
account_id=$(aws sts get-caller-identity --query "Account" --output text)
OIDC 제공자 URL은 클러스터 구성에서 추출할 수 있습니다:
oidc_provider=$(aws eks describe-cluster --name kube-cluster --region aws-region --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")echo $oidc_provideroidc.eks.eu-west-1.amazonaws.com/id/[...]
명령의 출력이 비어 있다면 위에서 언급한 대로 OIDC 제공자를 구성해야 합니다.
IAM 역할과 신뢰 관계를 생성하기 위해 다음 명령을 실행합니다:
cat >trust-relationship.json <<EOF{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::$account_id:oidc-provider/$oidc_provider" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "$oidc_provider:aud": "sts.amazonaws.com", "$oidc_provider:sub": "system:serviceaccount:teleport-agent:teleport-kube-agent-sa" } } } ]}EOF
IAM 역할을 생성하기 위해 다음 명령을 실행합니다:
aws iam create-role --role-name kube-iam-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
그 후, IAM 역할 주석과 함께 서비스 계정을 연결합니다:
kubectl annotate serviceaccount -n teleport-agent teleport-kube-agent-sa eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/kube-iam-role
이 시점에서 IAM 역할은 Teleport Kubernetes 서비스의 서비스 계정에서 사용될 준비가 완료되었습니다.
2/3단계. AWS 가입 토큰 생성
당신의 AWS 계정에 있는 에이전트가 정의된 역할을 사용하여 Teleport 클러스터에 조인할 수 있도록 하는 동적 토큰을 생성합니다.
기본적으로, Kubernetes 서비스 인스턴스는 허용 규칙과 일치하는 서명된 ID 문서를 전송하여 AWS 계정에서 실행 중임을 증명합니다.
AWS 가입 토큰에 대해 지정된 AWS 계정 및 에이전트가 실행될 AWS ARN을 정의하는 token.yaml
파일을 생성합니다.
cat >token.yaml <<EOFkind: tokenversion: v2metadata: # 토큰 이름은 비밀이 아니며, 인스턴스는 이 토큰을 사용하기 위해 # AWS 계정에서 실행 중임을 증명해야 합니다. name: kube-iam-tokenspec: # 필요한 최소 역할 집합을 사용합니다. roles: [Kube] # 이 토큰에 대해 허용된 조인 방법을 설정합니다. join_method: iam allow: # aws_arn은 선택 사항이며, 조인하는 Agents의 IAM 역할을 # 특정 IAM 역할로 제한하는 데 사용됩니다. - aws_account: "$account_id" aws_arn: "arn:aws:sts::$account_id:assumed-role/kube-iam-role/*"EOF
토큰을 생성하려면 tctl create token.yaml
을 실행합니다.
3/3단계. Teleport Kubernetes 서비스 배포
Teleport Helm 저장소를 설정합니다.
Helm이 Teleport Helm 저장소에서 호스팅되는 차트를 설치할 수 있도록 허용합니다:
helm repo add teleport https://charts.releases.teleport.dev
원격 저장소의 차트 캐시를 업데이트하여 모든 사용 가능한 릴리스로 업그레이드할 수 있습니다:
helm repo update
kubectl
을 Kubernetes 클러스터로 전환하고 다음을 실행합니다:
Kubernetes 에이전트를 배포합니다. Teleport 클러스터 tele.example.com으로 연결됩니다.
CLUSTER=iam-clusterPROXY=tele.example.com:443Teleport Kubernetes 에이전트를 설치합니다. 서비스 계정을 생성하지 않으며 기존
서비스 계정을 사용합니다. serviceAccount.create 및 serviceAccount.name 매개변수를 참조하십시오.
helm install teleport-agent teleport/teleport-kube-agent \ --set kubeClusterName=${CLUSTER?} \ --set roles="kube\,app\,discovery" \ --set proxyAddr=${PROXY?} \ --set joinParams.method=iam \ --set joinParams.tokenName=kube-iam-token \ --set serviceAccount.create=false \ --set serviceAccount.name=teleport-kube-agent-sa \ --create-namespace \ --namespace=teleport-agent \ --version 17.0.0-dev
Teleport 에이전트 pod가 실행 중인지 확인합니다. 하나의 준비된 컨테이너가 있는 Teleport 에이전트 pod를 확인할 수 있습니다:
kubectl -n teleport-agent get podsNAME READY STATUS RESTARTS AGEteleport-agent-0 1/1 Running 0 32s
tsh kube ls
를 사용하여 연결된 클러스터를 나열하고 tsh kube login
을 사용하여 클러스터 간 전환합니다:
tsh kube lsKube 클러스터 이름 선택됨
----------------- --------
iam-cluster
kubeconfig가 이제 iam-cluster 클러스터를 가리킵니다.
tsh kube login iam-clusterKubernetes 클러스터 "iam-cluster"에 로그인했습니다. 연결을 테스트하려면 'kubectl version'을 시도하십시오.
`iam-cluster` 에서 실행된 kubectl 명령어, 그러나 `tele.example.com` 클러스터를 통해 라우팅됩니다.
kubectl get pods
에이전트 pod가 정상이고 준비 상태인데도 Kubernetes 클러스터가 보이지 않으면, 이는 역할과 관련된 RBAC 권한과 관련이 있을 수 있습니다. 반면, Kubernetes 클러스터는 보이지만 pod가 보이지 않는 경우, 이는 Teleport 역할이 Kubernetes 클러스터의 pod에 대한 액세스를 허용하지 않기 때문일 수 있습니다. 두 경우 모두 아래 섹션을 참조하십시오.
Kubernetes 클러스터에 Teleport를 통해 인증하기 위해, 여러분의 Teleport 사용자 역할은 최소한 하나의 Kubernetes 사용자 또는 그룹에 대한 접근을 허용해야 합니다.
-
현재 사용자의 Teleport 역할 목록을 가져옵니다. 아래 예제는 JSON 파싱을 위해
jq
유틸리티가 필요합니다:CURRENT_ROLES=$(tsh status -f json | jq -r '.active.roles | join ("\n")') -
역할이 허용하는 Kubernetes 그룹을 가져옵니다:
echo "$CURRENT_ROLES" | xargs -I{} tctl get roles/{} --format json | \ jq '.[0].spec.allow.kubernetes_groups[]?' -
역할이 허용하는 Kubernetes 사용자를 가져옵니다:
echo "$CURRENT_ROLES" | xargs -I{} tctl get roles/{} --format json | \ jq '.[0].spec.allow.kubernetes_users[]?' -
이전 두 명령의 출력 중 하나라도 비어있지 않으면, 여러분의 사용자는 최소한 하나의 Kubernetes 사용자 또는 그룹에 접근할 수 있으므로 다음 단계로 진행할 수 있습니다.
-
두 목록이 모두 비어 있다면, 클러스터 내 Kubernetes 리소스를 볼 수 있는 Teleport 역할을 이 가이드를 위해 생성합니다.
kube-access.yaml
이라는 파일을 만들고 다음 내용을 추가합니다:kind: role metadata: name: kube-access version: v7 spec: allow: kubernetes_labels: "*": "*" kubernetes_resources: - kind: "*" namespace: "*" name: "*" verbs: ["*"] kubernetes_groups: - viewers deny: {}
-
변경 사항을 적용합니다:
tctl create -f kube-access.yaml -
kube-access
역할을 Teleport 사용자에게 할당하려면, 인증 제공자에 맞는 적절한 명령어를 실행하십시오:-
로컬 사용자의 역할을 쉼표로 구분된 목록으로 가져옵니다:
ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")') -
새로운 역할을 추가하기 위해 로컬 사용자를 수정합니다:
tctl users update $(tsh status -f json | jq -r '.active.username') \ --set-roles "${ROLES?},kube-access" -
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.
-
텍스트 편집기에서
github
인증 커넥터를 엽니다:tctl edit github/github -
github
커넥터를 수정하여teams_to_roles
섹션에kube-access
을 추가합니다.이 역할에 매핑해야 하는 팀은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 팀은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 팀이어야 합니다.
예시는 다음과 같습니다:
teams_to_roles: - organization: octocats team: admins roles: - access + - kube-access
-
파일을 편집하고 저장하여 변경 사항을 적용합니다.
-
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.
-
saml
구성 리소스를 가져옵니다:tctl get --with-secrets saml/mysaml > saml.yaml--with-secrets
플래그는spec.signing_key_pair.private_key
의 값을saml.yaml
파일에 추가합니다. 이 키는 민감한 값을 포함하므로, 리소스를 업데이트한 후 즉시saml.yaml
파일을 삭제해야 합니다. -
saml.yaml
을 수정하여attributes_to_roles
섹션에kube-access
을 추가합니다.이 역할에 매핑해야 하는 속성은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 그룹은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 그룹이어야 합니다.
예시는 다음과 같습니다:
attributes_to_roles: - name: "groups" value: "my-group" roles: - access + - kube-access
-
변경 사항을 적용합니다:
tctl create -f saml.yaml -
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.
-
oidc
구성 리소스를 가져옵니다:tctl get oidc/myoidc --with-secrets > oidc.yaml--with-secrets
플래그는spec.signing_key_pair.private_key
의 값을oidc.yaml
파일에 추가합니다. 이 키는 민감한 값을 포함하므로, 리소스를 업데이트한 후 즉시oidc.yaml
파일을 삭제해야 합니다. -
oidc.yaml
을 수정하여claims_to_roles
섹션에kube-access
을 추가합니다.이 역할에 매핑해야 하는 클레임은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 그룹은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 그룹이어야 합니다.
예시는 다음과 같습니다:
claims_to_roles: - name: "groups" value: "my-group" roles: - access + - kube-access
-
변경 사항을 적용합니다:
tctl create -f oidc.yaml -
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.
-
-
Kubernetes 클러스터 내에서
viewers
그룹이 기본 제공view
ClusterRole을 갖도록 구성합니다. 여러분의 Teleport 사용자가kube-access
역할을 맡고 Kubernetes API 서버에 요청을 보낼 때, Teleport Kubernetes 서비스가viewers
그룹으로 가장하여 요청을 프록시합니다.viewers-bind.yaml
이라는 파일을 만들고 다음 내용을 추가합니다. 이는 여러분이 Teleport 사용자가 접근할 수 있도록 활성화한viewers
그룹과 기본 제공view
ClusterRole을 바인딩합니다:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: viewers-crb subjects: - kind: Group # "kube-access" 역할을 통해 위에서 할당한 kubernetes_groups에 해당하는 "viewers" 그룹을 바인딩 name: viewers apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole # "view"는 리소스에 대한 읽기 전용 접근을 부여하는 기본 제공 ClusterRole입니다 # 참조: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles name: view apiGroup: rbac.authorization.k8s.io
-
kubectl
로ClusterRoleBinding
을 적용합니다:kubectl apply -f viewers-bind.yaml
다음 단계
teleport-kube-agent
Helm 차트의 values 파일에서 설정할 수 있는 모든 옵션을 보려면 참조 가이드를 참조하십시오.