Infograb logo
IAM 조인을 사용하여 Kubernetes 클러스터 등록

이 안내서에서는 에이전트의 IAM 아이덴티티를 사용하여 Teleport 클러스터에 자동으로 가입하는 방법을 보여줍니다.

Teleport에 여러 Kubernetes 클러스터를 등록할 수 있으며, 등록할 각 클러스터에 Teleport Kubernetes 서비스를 배포할 수 있습니다. 이 경우, Kubernetes 클러스터에 조인 비밀을 배포할 필요가 없습니다.

Kubernetes 클러스터가 처음 등록되면 에이전트는 Kubernetes 비밀에 자신의 Teleport 아이덴티티를 저장합니다. 에이전트는 이후 재시작 시 이 아이덴티티를 사용하여 클러스터에 자동으로 가입합니다.

Proxy Service와 함께 7 계층 로드 밸런서 또는 리버스 프록시를 사용하여 클러스터에 가입하는 지원이 Teleport 13.0+에서 가능합니다.

사전 요구 사항

  • 실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.

  • tctl 관리 도구와 tsh 클라이언트 도구.

    tctltsh 다운로드에 대한 지침은 설치를 방문하세요.

  • Kubernetes 클러스터 버전 >= v1.17.0
  • 클러스터를 위한 기존 IAM OpenID Connect (OIDC) 제공자
  • Helm >= 3.4.2
  • AWS CLI >= 2.10.3 또는 1.27.81

Helm과 Kubernetes가 설치되어 있고 최신 상태인지 확인하세요.

helm version

version.BuildInfo{Version:"v3.4.2"}


kubectl version

클라이언트 버전: version.Info{Major:"1", Minor:"17+"}

서버 버전: version.Info{Major:"1", Minor:"17+"}

  • 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
    tsh login --proxy=teleport.example.com --user=email@example.com
    tctl status

    클러스터 teleport.example.com

    버전 16.2.0

    CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

    클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1단계/3. IAM 아이덴티티로 Kubernetes 서비스 계정 만들기

Teleport는 AWS에서 실행 중인 에이전트가 실행 중인 IAM 아이덴티티를 사용하여 클러스터에 가입할 수 있는 모드를 지원합니다. 이를 통해 Kubernetes 클러스터에 조인 비밀을 배포할 필요 없이 AWS에서 실행 중인 Kubernetes 클러스터를 등록할 수 있습니다.

EKS 노드의 아이덴티티에 의존하지 않고 안전하게 클러스터에 가입하기 위해, Teleport 에이전트는 IAM 역할이 부착된 별도의 Kubernetes 서비스 계정으로 실행되어야 합니다. 노드의 아이덴티티에 의존하는 것은 권장되지 않으며, 이는 IAM 역할을 서비스 계정에 대해 구성하지 않은 경우 노드에서 실행 중인 모든 pod가 노드의 아이덴티티에 접근할 수 있기 때문입니다.

IRSA가 올바르게 작동하려면 Kubernetes 클러스터가 IAM OpenID Connect를 가지고 있어야 하며, 여기서 IAM 역할은 Kubernetes 서비스 계정에 매핑됩니다.

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-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 <<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 조인 토큰 만들기

에이전트가 정의된 역할을 사용하여 Teleport 클러스터에 가입할 수 있도록 허용하는 동적 토큰을 생성합니다.

Kubernetes 서비스 인스턴스는 현재 AWS 계정에서 실행되고 있음을 입증하기 위해 사인된 아이덴티티 문서를 전송합니다. 이는 AWS 조인 토큰에 구성된 허용 규칙과 일치해야 합니다.

다음 규칙을 지정하는 token.yaml을 생성합니다.

cat >token.yaml <<EOFkind: tokenversion: v2metadata: # 토큰 이름은 비밀이 아니며 인스턴스는 # 이 토큰을 사용하기 위해 AWS 계정에서 실행되고 있음을 증명해야 합니다. name: kube-iam-tokenspec: # 필요한 최소한의 역할 집합 사용 roles: [Kube] # 이 토큰에 대해 허용되는 조인 방법 설정 join_method: iam allow: # aws_arn은 선택 사항이며 조인 에이전트의 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 리포지토리를 설정하세요. Teleport Helm 리포지토리에 호스팅된 차트를 설치하도록 Helm을 허용하세요:

helm repo add teleport https://charts.releases.teleport.dev

원격 리포지토리의 차트 캐시를 업데이트하여 모든 사용 가능한 릴리즈로 업그레이드할 수 있습니다:

helm repo update

kubectl을 Kubernetes 클러스터로 전환하고 실행합니다:

Kubernetes 에이전트를 배포합니다. Teleport 클러스터 tele.example.com에 다시 전화합니다.

CLUSTER=iam-cluster
PROXY=tele.example.com:443

기존 서비스 계정을 사용하고 서비스 계정을 생성하지 않고 Teleport Kubernetes 에이전트를 설치합니다.

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 16.2.0

Teleport 에이전트 pod가 실행 중인지 확인하십시오. 다음과 같은 메시지가 표시됩니다:

kubectl -n teleport-agent get pods
NAME READY STATUS RESTARTS AGEteleport-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'을 시도하십시오.


`iam-cluster`에서 실행된 kubectl 명령이 `tele.example.com` 클러스터를 통해 라우팅됩니다.

kubectl get pods

에이전트 pod가 건강하고 준비 상태지만 Kubernetes 클러스터가 보이지 않는 경우, 이는 역할과 관련된 RBAC 권한과 관련이 있을 수 있습니다. 반면, Kubernetes 클러스터가 보이지만 pod가 보이지 않을 경우, 이는 Teleport 역할이 Kubernetes 클러스터의 pod에 대한 접근을 허용하지 않는 경우일 수 있습니다. 이 두 경우 모두 아래 섹션을 참조하십시오.

Kubernetes 클러스터에 Teleport를 통해 인증하기 위해, Teleport 사용자 역할이 최소한 하나의 Kubernetes 사용자 또는 그룹에 대한 접근을 허용해야 합니다.

  1. 현재 사용자의 Teleport 역할 목록을 검색합니다. 아래 예제는 JSON 파싱을 위해 jq 유틸리티가 필요합니다:

    CURRENT_ROLES=$(tsh status -f json | jq -r '.active.roles | join ("\n")')
  2. 역할이 허용하는 Kubernetes 그룹을 검색합니다:

    echo "$CURRENT_ROLES" | xargs -I{} tctl get roles/{} --format json | \ jq '.[0].spec.allow.kubernetes_groups[]?'
  3. 역할이 허용하는 Kubernetes 사용자를 검색합니다:

    echo "$CURRENT_ROLES" | xargs -I{} tctl get roles/{} --format json | \ jq '.[0].spec.allow.kubernetes_users[]?'
  4. 이전 두 명령 중 하나의 출력이 비어 있지 않다면, 사용자가 최소한 하나의 Kubernetes 사용자 또는 그룹에 접근할 수 있으므로 다음 단계로 진행할 수 있습니다.

  5. 두 목록이 모두 비어 있다면, 이 가이드를 위해 클러스터 내 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: {}
    
  6. 변경 사항을 적용합니다:

    tctl create -f kube-access.yaml
  7. kube-access 역할을 Teleport 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:

    1. 로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:

      ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
    2. 로컬 사용자를 편집하여 새로운 역할을 추가합니다:

      tctl users update $(tsh status -f json | jq -r '.active.username') \ --set-roles "${ROLES?},kube-access"
    3. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

    1. github 인증 커넥터를 가져옵니다:

      tctl get github/github --with-secrets > github.yaml

      --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.

    2. github.yaml을 편집하고 teams_to_roles 섹션에 kube-access을 추가합니다.

      이 역할에 매핑할 팀은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 하지만 팀에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 팀이어야 합니다.

      여기에 예시가 있습니다:

        teams_to_roles:
          - organization: octocats
            team: admins
            roles:
              - access
      +       - kube-access
      
    3. 변경 사항을 적용합니다:

      tctl create -f github.yaml
    4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

    1. saml 구성 리소스를 가져옵니다:

      tctl get --with-secrets saml/mysaml > saml.yaml

      --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.

    2. saml.yaml을 편집하고 attributes_to_roles 섹션에 kube-access을 추가합니다.

      이 역할에 매핑할 속성은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

      여기에 예시가 있습니다:

        attributes_to_roles:
          - name: "groups"
            value: "my-group"
            roles:
              - access
      +       - kube-access
      
    3. 변경 사항을 적용합니다:

      tctl create -f saml.yaml
    4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

    1. oidc 구성 리소스를 가져옵니다:

      tctl get oidc/myoidc --with-secrets > oidc.yaml

      --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.

    2. oidc.yaml을 편집하고 claims_to_roles 섹션에 kube-access을 추가합니다.

      이 역할에 매핑할 클레임은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

      여기에 예시가 있습니다:

        claims_to_roles:
          - name: "groups"
            value: "my-group"
            roles:
              - access
      +       - kube-access
      
    3. 변경 사항을 적용합니다:

      tctl create -f oidc.yaml
    4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

  8. Kubernetes 클러스터에서 viewers 그룹을 내장된 view ClusterRole을 가지도록 구성합니다. 사용자가 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
    
  9. kubectl을 사용하여 ClusterRoleBinding을 적용합니다:

    kubectl apply -f viewers-bind.yaml

다음 단계

teleport-kube-agent Helm 차트에 대해 값을 설정할 수 있는 모든 옵션을 보려면 레퍼런스 가이드를 참조하십시오.

Teleport 원문 보기