IAM 조인을 사용한 Kubernetes 클러스터 등록
Teleport v18.9이 가이드에서는 에이전트의 IAM 자격 증명을 사용하여 Teleport 클러스터에 자동으로 조인하는 방식으로 Kubernetes 클러스터를 Teleport에 등록하는 방법을 보여드립니다. 조인 시크릿을 Kubernetes 클러스터에 배포할 필요 없이 등록하려는 각 클러스터에 Teleport Kubernetes 서비스를 배포하여 여러 Kubernetes 클러스터를 Teleport에 등록할 수 있습니다.
이 가이드에서는 에이전트의 IAM 자격 증명을 사용하여 Teleport 클러스터에 자동으로 조인하는 방식으로 Kubernetes 클러스터를 Teleport에 등록하는 방법을 보여드립니다.
작동 방식#
조인 시크릿을 Kubernetes 클러스터에 배포할 필요 없이 등록하려는 각 클러스터에 Teleport Kubernetes 서비스를 배포하여 여러 Kubernetes 클러스터를 Teleport에 등록할 수 있습니다.
Kubernetes 클러스터가 처음 등록되면 에이전트는 Teleport 자격 증명을 Kubernetes 시크릿에 저장합니다. 에이전트는 이후 재시작 시 이 자격 증명을 사용하여 클러스터에 자동으로 조인합니다.
사전 요구사항#
-
실행 중인 Teleport 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.
-
tctlandtshclients.Installing `tctl` and `tsh` clients
-
Teleport 클러스터의 버전을 확인합니다.
tctlandtshclients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의/v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다.teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:$ TELEPORT_DOMAIN=teleport.example.com:443 $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')" -
사용 중인 플랫폼에 대한 지침에 따라
tctlandtshclients를 설치합니다:
-
Mac
`tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
```code
$ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
```
Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
보장할 수 없습니다.
Windows - Powershell
```code
$ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
# Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
# NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
# Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
```
Linux
Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다. RPM/DEB
패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
[설치 페이지](../installation/installation.mdx)를 참조하세요.
```code
$ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
$ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
$ cd teleport
$ sudo ./install
# Teleport binaries have been copied to /usr/local/bin
```
- Kubernetes 클러스터 버전 >=
v
[kubernetes.major_version].[kubernetes.minor_version].0 - 클러스터에 대한 기존 IAM OpenID Connect (OIDC) 공급자
- Helm >=
[helm.version] - AWS CLI >=
2.10.3또는1.27.81
Helm과 Kubernetes가 설치되어 있고 최신 상태인지 확인합니다.
$ helm version
# version.BuildInfo{Version:"v(=helm.version=)"}
$ kubectl version
# Client Version: version.Info{Major:"(=kubernetes.major_version=)", Minor:"(=kubernetes.minor_version=)+"}
# Server Version: version.Info{Major:"(=kubernetes.major_version=)", Minor:"(=kubernetes.minor_version=)+"}
Teleport cluster에 연결할 수 있는지 확인하려면 tsh login으로 로그인한 다음,
현재 자격 증명으로 tctl 명령을 실행할 수 있는지 확인합니다.
예를 들어, teleport.example.com에 cluster 내 Teleport Proxy Service의
도메인 이름을, email@example.com에 Teleport 사용자 이름을 지정하여
다음 명령을 실행합니다:
$ tsh login --proxy=teleport.example.com --user=email@example.com
$ tctl status
# Cluster (=teleport.url=)
# Version (=teleport.version=)
# CA pin (=presets.ca_pin=)
cluster에 연결하여 tctl status 명령을 실행할 수 있다면, 현재 자격 증명을 사용하여
워크스테이션에서 이후의 tctl 명령을 실행할 수 있습니다.
자체 Teleport cluster를 호스팅하는 경우, 전체 권한을 얻기 위해 Teleport Auth Service를
호스팅하는 컴퓨터에서 tctl 명령을 실행할 수도 있습니다.
1/3단계. IAM 자격 증명을 가진 Kubernetes 서비스 계정 생성#
Teleport는 AWS에서 실행 중인 에이전트가 실행 중인 IAM 자격 증명을 사용하여 클러스터에 조인할 수 있는 모드를 지원합니다. 이를 통해 Kubernetes 클러스터에 조인 시크릿을 배포하지 않고도 AWS에서 실행 중인 Kubernetes 클러스터를 등록할 수 있습니다.
EKS 노드의 자격 증명에 의존하지 않고 클러스터에 안전하게 조인하려면 Teleport 에이전트가 IAM 역할이 연결된 별도의 Kubernetes 서비스 계정으로 실행되어야 합니다. IAM Roles for Service Accounts(IRSA)가 구성되지 않은 경우 노드에서 실행되는 모든 파드가 노드의 자격 증명에 접근할 수 있으므로 노드의 자격 증명에 의존하는 것은 권장하지 않습니다.
IRSA가 올바르게 작동하려면 Kubernetes 클러스터에 IAM 역할을 Kubernetes 서비스 계정에 매핑하는 IAM OpenID Connect가 필요합니다.
Kubernetes 서비스 계정은 sts:GetCallerIdentity API에 접근할 수 있어야 하지만 다른 권한은 필요하지 않습니다.
IAM 정책을 생성하려면 다음 명령을 실행합니다:
$ cat >iam-policy.json <
그런 다음 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을 사용하여 클러스터를 프로비저닝했다면 이를 사용하거나 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 서비스 계정이 생성됩니다.
AWS CLI를 사용하여 새 IAM 역할을 생성하고 대상 네임스페이스의 Kubernetes 서비스 계정에 매핑하려면 몇 가지 추가 단계가 필요합니다.
먼저 Kubernetes 클러스터에 대상 네임스페이스와 Kubernetes 서비스 계정을 생성해야 합니다.
$ kubectl create ns teleport-agent
namespace/teleport-agent created
$ kubectl create sa teleport-kube-agent-sa -n teleport-agent
serviceaccount/teleport-kube-agent-sa created
그런 다음 IAM 역할과 신뢰 관계를 생성해야 합니다. 이를 위해 AWS 계정 ID와 OIDC 공급자 URL을 얻어야 합니다. 클러스터에 구성된 것이 없다면 다음 가이드를 확인하세요: 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_provider
oidc.eks.eu-west-1.amazonaws.com/id/[...]
명령의 출력이 비어 있다면 위에서 언급한 대로 OIDC 공급자를 구성해야 합니다.
IAM 역할과 신뢰 관계를 생성하려면 다음 명령을 실행합니다:
$ cat >trust-relationship.json <
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 서비스 인스턴스는 AWS 조인 토큰에 구성된 허용 규칙과 일치하는 서명된 자격 증명 문서를 보내 AWS 계정에서 실행 중임을 증명합니다.
AWS 계정과 에이전트가 실행할 AWS ARN을 지정하는 allow 규칙이 있는 token.yaml을 생성합니다.
$ cat >token.yaml <
tctl create token.yaml을 실행하여 토큰을 생성합니다.
3/3단계. Teleport Kubernetes 서비스 배포#
Teleport Helm 리포지토리에서 Teleport 차트를 가져오도록 Helm을 구성하십시오.
$ helm repo add teleport (=teleport.helm_repo_url=)
최신 차트를 가져와 로컬 Helm 캐시를 새로 고치십시오.
$ helm repo update
kubectl을 Kubernetes 클러스터로 전환하고 실행합니다:
# Kubernetes 에이전트를 배포합니다. tele.example.com Teleport 클러스터로 다이얼백합니다.
$ CLUSTER=iam-cluster
$ PROXY=tele.example.com:443
# Teleport Kubernetes 에이전트를 설치합니다. 서비스 계정을 생성하지 않고 기존
# 서비스 계정을 사용합니다. serviceAccount.create 및 serviceAccount.name 매개변수를 참조하세요.
$ helm install teleport-agent teleport/teleport-kube-agent \
--set kubeClusterName=${CLUSTER?} \
--set roles="kube" \
--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 (=teleport.version=)
Teleport 에이전트 파드가 실행 중인지 확인합니다. 단일 준비 컨테이너가 있는 하나의 Teleport 에이전트 파드가 표시되어야 합니다:
$ kubectl -n teleport-agent get pods
NAME READY STATUS RESTARTS AGE
teleport-agent-0 1/1 Running 0 32s
tsh kube ls를 사용하여 연결된 클러스터를 나열하고 tsh kube login을 사용하여 전환합니다:
$ tsh kube ls
# Kube Cluster Name Selected
# ----------------- --------
# iam-cluster
# kubeconfig가 이제 iam-cluster 클러스터를 가리킵니다
$ tsh kube login iam-cluster
# Kubernetes 클러스터 "iam-cluster"에 로그인했습니다. 'kubectl version'으로 연결을 테스트해보세요.
# kubectl 명령은 `iam-cluster`에서 실행되지만 `tele.example.com` 클러스터를 통해 라우팅됩니다.
$ kubectl get pods
에이전트 파드가 정상이고 준비되어 있지만 Kubernetes 클러스터가 보이지 않는다면 역할과 관련된 RBAC 권한 문제일 가능성이 높습니다. 반면 Kubernetes 클러스터가 보이지만 파드가 보이지 않는다면 Teleport 역할이 Kubernetes 클러스터의 파드에 대한 접근을 허용하지 않는 것입니다. 두 경우 모두 아래 섹션을 참조하세요.
Kubernetes 클러스터가 보이지 않나요?
Teleport를 통해 Kubernetes 클러스터에 인증하려면, 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
Web UI를 사용하여 역할을 생성하고 편집할 수도 있습니다. Access -> Roles로 이동하여 Create New Role을 클릭하거나 편집할 기존 역할을 선택하십시오.
인증 공급자에 맞는 적절한 명령을 실행하여 kube-access 역할을
your Teleport user에게 할당하십시오:
Local User
-
로컬 사용자의 역할을 쉼표로 구분된 목록으로 가져옵니다:
$ 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
-
텍스트 편집기에서
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
-
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
-
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그룹이 내장viewClusterRole을 갖도록 구성합니다. Teleport 사용자가kube-access역할을 맡아 Kubernetes API 서버로 요청을 보내면, Teleport Kubernetes Service가viewers그룹을 가장(impersonate)하여 요청을 프록시합니다.다음 내용으로
viewers-bind.yaml파일을 생성하여, 내장viewClusterRole을 Teleport 사용자가 접근할 수 있도록 활성화한viewers그룹에 바인딩합니다.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: viewers-crb subjects: - kind: Group # Bind the group "viewers", corresponding to the kubernetes_groups we assigned our "kube-access" role above name: viewers apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole # "view" is a default ClusterRole that grants read-only access to resources # See: 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 차트의 값 파일에서 설정할 수 있는 모든 옵션을 보려면 참조 가이드를 참조하세요.