Teleport Kubernetes 서비스는 Kubernetes 사용자와 하나 이상의 Kubernetes 클러스터 사이에 위치하는 프록시입니다.

이 가이드에서는 로컬 Kubernetes 클러스터를 사용하여 Teleport의 역할 기반 접근 제어(RBAC) 시스템을 구성하고 Kubernetes 클러스터, 그룹, 사용자 및 리소스에 대한 접근을 관리하는 방법을 보여드립니다.

작동 방식#

사용자가 Teleport에 인증하면, Teleport Kubernetes 서비스를 통해 인가된 Kubernetes 클러스터에 요청을 보낼 수 있는 kubeconfig를 받게 됩니다. Kubernetes 서비스는 역할을 통해 Teleport 사용자에게 할당된 권한에 따라 이러한 요청을 검사, 수정 또는 거부할 수 있습니다.

사전 요구사항#

• 실행 중인 Teleport 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.

• tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Teleport 클러스터의 버전을 확인합니다. tctl and tsh clients는 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')"
     

  2. 사용 중인 플랫폼에 대한 지침에 따라 tctl and tsh clients를 설치합니다:

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
     ```
   

 

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단계. Kubernetes 리소스 준비#

minikube 시작#

Docker 드라이버로 minikube를 시작합니다:

$ minikube start --driver=docker

이 명령은 로컬 Kubernetes 클러스터를 시작하고 컨텍스트를 minikube로 설정합니다. 이를 확인하려면 다음 명령을 실행하세요:

$ kubectl config current-context
minikube

데모 파드 배포#

워크스테이션에서 다음 내용으로 pods.yaml이라는 매니페스트 파일을 생성합니다:

apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    name: development
---
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    name: production
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: development
spec:
  selector:
    matchLabels:
      app: nginx-webapp
  template:
    metadata:
      labels:
        app: nginx-webapp
    spec:
      containers:
        - name: nginx
          image: nginx:1.23
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: production
spec:
  selector:
    matchLabels:
      app: nginx-webapp
  template:
    metadata:
      labels:
        app: nginx-webapp
    spec:
      containers:
        - name: nginx
          image: nginx:1.23
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: loadbalancer
  namespace: development
spec:
  selector:
    matchLabels:
      app: nginx-loadbalancer
  template:
    metadata:
      labels:
        app: nginx-loadbalancer
    spec:
      containers:
        - name: nginx
          image: nginx:1.23
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: loadbalancer
  namespace: production
spec:
  selector:
    matchLabels:
      app: nginx-loadbalancer
  template:
    metadata:
      labels:
        app: nginx-loadbalancer
    spec:
      containers:
        - name: nginx
          image: nginx:1.23

이 매니페스트는 development와 production 두 개의 네임스페이스를 생성하고 각각에 두 개의 nginx 파드(webapp과 loadbalancer)를 배포합니다. 새 리소스를 적용합니다:

$ kubectl apply -f pods.yaml

리소스가 배포되었는지 확인합니다:

$ kubectl -n development get pods
$ kubectl -n production get pods

각 네임스페이스에서 loadbalancer와 webapp 파드가 모두 보여야 합니다.

Kubernetes RBAC 리소스 설치#

이제 development와 production 네임스페이스에 webapp과 loadbalancer 파드를 배포했으므로, 모든 네임스페이스의 모든 파드를 볼 수 있는 Kubernetes 역할을 생성하겠습니다. 이 가이드의 뒷부분에서 Teleport 사용자가 클러스터의 리소스에 가질 수 있는 접근을 더 제한하는 Teleport 역할을 정의할 것입니다.

다음 내용으로 k8s-rbac.yaml이라는 매니페스트 파일을 생성합니다:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-viewer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-viewer
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-viewer
  apiGroup: rbac.authorization.k8s.io

변경사항을 적용합니다:

$ kubectl apply -f k8s-rbac.yaml

Teleport Kubernetes 서비스 설치#

Kubernetes에서 일부 워크로드가 실행되고 이에 대한 접근을 관리하는 RBAC 리소스가 있으므로, 이제 Kubernetes 사용자가 접근할 수 있는 리소스를 더 세밀하게 제어할 수 있도록 데모 클러스터에 Teleport Kubernetes 서비스를 설치합니다.

Teleport Helm 리포지토리에서 Teleport 차트를 가져오도록 Helm을 구성하십시오.

$ helm repo add teleport (=teleport.helm_repo_url=)

최신 차트를 가져와 로컬 Helm 캐시를 새로 고치십시오.

$ helm repo update

Kubernetes 서비스가 Teleport 클러스터에 조인하는 데 사용할 토큰을 요청합니다:

$ tctl tokens add --type=kube,app,discovery --ttl=1h --format=text

이 토큰을 복사하여 Teleport Kubernetes 서비스를 실행할 때 사용할 수 있도록 안전한 곳에 보관합니다.

Teleport Proxy 서비스의 호스트 및 포트를 proxy-address에 할당하고(예: mytenant.teleport.sh:443), 앞에서 요청한 토큰을 token에 할당하여 클러스터에 Teleport Kubernetes 서비스를 설치합니다:

$ helm install teleport-agent teleport/teleport-kube-agent \
  --set kubeClusterName=minikube \
  --set roles="kube\,app\,discovery" \
  --set proxyAddr=proxy-address \
  --set authToken=token \
  --set labels.region=local --set labels.platform=minikube \
  --create-namespace \
  --namespace=teleport-agent \
  --version (=teleport.version=)

이 helm install 명령은 곧 추가될 Kubernetes 서비스 인스턴스에 두 개의 레이블(region:local 및 platform:minikube)을 제공합니다. 이 가이드의 후반부에서 클러스터에 대한 접근 제어를 구성할 때 이를 사용할 것입니다.

teleport 파드가 클러스터에서 실행 중인지 확인합니다:

$ kubectl -n teleport-agent get pods

다음 명령을 실행하여 Teleport Kubernetes 서비스가 Teleport 클러스터에 등록되었는지 확인할 수 있습니다:

$ tctl get kube_servers

출력은 다음과 유사해야 합니다:

kind: kube_server
metadata:
  expires: "2023-01-24T16:20:00.571214635Z"
  id: 0000000000000000000
  name: minikube
spec:
  cluster:
    kind: kube_cluster
    metadata:
      labels:
        platform: minikube
        region: local
      name: minikube
    spec:
      aws: {}
      azure: {}
      gcp: {}
    version: v3
  host_id: 00000000-0000-0000-0000-000000000000
  hostname: remote.kube.proxy.teleport.cluster.local
  rotation:
    current_id: ""
    last_rotated: "0001-01-01T00:00:00Z"
    schedule:
      standby: "0001-01-01T00:00:00Z"
      update_clients: "0001-01-01T00:00:00Z"
      update_servers: "0001-01-01T00:00:00Z"
    started: "0001-01-01T00:00:00Z"
  version: (=teleport.version=)
version: v3

2/3단계. Teleport 역할 정의#

Teleport Kubernetes 서비스는 사용자의 역할을 조회하여 Kubernetes API 서버에 대한 Teleport 사용자의 요청을 프록시하는 방법을 결정합니다. 이 정보를 기반으로 Kubernetes 서비스는 요청을 수락하거나 거부합니다.

유효한 요청에 대해 Kubernetes 서비스는 요청 헤더를 재작성하여 Teleport 사용자가 원하는 Kubernetes 사용자 및 그룹으로 가장(impersonate)하고, 요청을 API 서버로 전달합니다.

이 섹션에서는 다음을 수행하는 Teleport 역할을 정의합니다:

• 사용자를 developers 그룹의 멤버로 Kubernetes 클러스터에 인증합니다. 이전 섹션에서 이 그룹의 멤버에게 모든 네임스페이스의 파드를 볼 수 있도록 권한을 부여했습니다.
• 사용자가 production 네임스페이스의 webapp 파드와 development 네임스페이스의 모든 파드에 접근할 수 있도록 합니다.
• 다른 모든 파드에 대한 접근을 거부합니다.

역할 정의#

다음 내용으로 kube-access.yaml이라는 파일을 생성합니다:

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      'region': '*'
      'platform': 'minikube'
    kubernetes_resources:
      - kind: pod
        namespace: "production"
        name: "^webapp-[a-z0-9-]+$"
      - kind: pod
        namespace: "development"
        name: "*"
    kubernetes_groups:
    - developers
    kubernetes_users:
    - minikube
  deny: {}

이 역할에서 다음 allow 규칙을 정의했습니다:

• kubernetes_labels: 모든 지역의 Kubernetes 클러스터에 대한 접근을 허용하지만, platform:minikube 레이블이 있는 클러스터만 허용합니다.
• kubernetes_resources: production 네임스페이스의 webapp 배포의 파드와 development 네임스페이스의 모든 파드에 대한 접근을 허용합니다. Kubernetes가 자동으로 생성하는 파드 이름을 매칭하기 위해 정규 표현식(^으로 시작하고 $로 끝남)을 사용한 것에 주목하세요.
• kubernetes_groups: 이 가이드의 앞부분에서 pod-viewer Kubernetes Role과 연결한 Kubernetes 그룹 developers의 멤버로 사용자를 Kubernetes 클러스터에 인증합니다.
• kubernetes_users: 기본 minikube 사용자로 사용자를 Kubernetes 클러스터에 인증합니다.

역할 생성#

kube-access 역할 구성을 완료한 후 다음 명령으로 생성합니다:

$ tctl create kube-access.yaml

인증 공급자에 맞는 적절한 명령을 실행하여 kube-access 역할을 your Teleport user에게 할당하십시오:

Local User

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 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

GitHub

1. 텍스트 편집기에서 github 인증 커넥터를 엽니다:

   $ tctl edit github/github
   

2. github 커넥터를 편집하여 teams_to_roles 섹션에 kube-access을 추가합니다.

   이 역할에 매핑해야 할 팀은 조직의 역할 기반 액세스 제어(RBAC)를 어떻게 설계했는지에 따라 달라집니다. 다만, 해당 팀은 여러분의 사용자 계정을 포함해야 하며 조직 내에서 가능한 한 가장 작은 팀이어야 합니다.

   다음은 예시입니다:

     teams_to_roles:
       - organization: octocats
         team: admins
         roles:
           - access
   +       - kube-access
   

3. 편집기에서 파일을 저장하고 닫아 변경 사항을 적용합니다.

4. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

SAML

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 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

OIDC

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 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

3/3단계. 리소스 접근#

이 시점에서 Teleport Kubernetes 서비스를 구성하여 Teleport 사용자가 production 네임스페이스의 webapp 파드에 접근할 수 있도록 했습니다. 이 단계에서는 Teleport를 통해 Kubernetes 클러스터에 인증하고 새로운 접근 제어를 테스트합니다.

Teleport를 통해 접근할 수 있는 Kubernetes 클러스터를 나열합니다:

$ tsh kube ls

앞에서 등록한 minikube 클러스터가 보여야 합니다:

Kube Cluster Name Labels                         Selected
----------------- ------------------------------ --------
minikube          platform=minikube region=local

Teleport를 통해 Kubernetes 클러스터에 접근하려면 인증하고 kubeconfig를 업데이트합니다:

$ tsh kube login minikube

모든 네임스페이스의 파드를 나열할 때, Teleport Kubernetes 서비스는 검색된 파드를 필터링하여 Teleport 사용자가 접근할 수 있는 파드만 표시합니다. 다음 명령을 실행합니다:

$ kubectl get pods --all-namespaces

출력에는 production 네임스페이스의 webapp 파드와 development 네임스페이스의 webapp 및 loadbalancer 파드가 모두 표시됩니다:

NAMESPACE     NAME                           READY   STATUS    RESTARTS   AGE
development   loadbalancer-000000000-00000   1/1     Running   0          36m
development   webapp-0000000000-00000        1/1     Running   0          36m
production    webapp-0000000000-00000        1/1     Running   0          36m

production 네임스페이스의 webapp 파드에 대한 정보에 접근할 수 있습니다:

$ kubectl -n production get pods/webapp-0000000000-00000 -o json

또한 앞에서 생성한 kube-access 역할이 Teleport 사용자를 developers Kubernetes 그룹에 매핑했으며, 이 그룹은 파드 보기 권한만 가지고 있음을 주목하세요:

$ kubectl auth can-i create pods
no

Teleport 역할과 Kubernetes RBAC 리소스를 구성함으로써 조직의 사용자가 Kubernetes 기반 인프라에 가질 수 있는 접근을 세밀하게 조정할 수 있습니다.

tsh kube login을 통해 minikube 클러스터에 인증했을 때, Teleport는 Teleport를 통해 클러스터에 연결하는 kubeconfig를 생성했습니다:

$ kubectl config current-context
teleport.example.com-minikube

minikube 클러스터에 대한 완전한 제어를 다시 얻고 싶다면 기본 minikube 컨텍스트를 대신 사용할 수 있습니다:

$ kubectl config use-context minikube

다음 단계#

Teleport RBAC가 Kubernetes에서 작동하는 방식에 대한 자세한 정보는 Kubernetes 접근 제어 가이드를 참조하세요. 다양한 Teleport 및 Kubernetes RBAC 구성을 시험해보기 위해 minikube 클러스터를 계속 실행해 둘 수 있습니다.

이제 Kubernetes 클러스터에 대한 접근을 제어하기 위해 Teleport의 RBAC 시스템을 구성하는 방법을 배웠으니, 즉시 접근을 위한 리소스 접근 요청과 선택한 커뮤니케이션 워크플로로 접근을 관리하기 위한 접근 요청 플러그인 설정 방법을 알아보세요.