Kubernetes를 위한 Teleport 액세스 제어 설정

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

사용자가 Teleport에 인증하면, 그들은 Teleport Kubernetes 서비스를 통해 권한이 부여된 Kubernetes 클러스터에 요청을 보낼 수 있는 kubeconfig를 받습니다. 그런 다음 Kubernetes 서비스는 Teleport 사용자에게 할당된 권한에 따라 이러한 요청을 검사하거나 수정하거나 허용하지 않을 수 있습니다.

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

전제 조건

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

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

당신의 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 명령어를 실행할 수도 있습니다.

로컬 데모 환경을 실행하려면, 작업 공간에 다음 도구들이 설치되어 있어야 합니다:

도구	목적	설치 링크
minikube	로컬 Kubernetes 배포 도구	Minikube 설치하기
Helm	Kubernetes 패키지 관리자	Helm 설치하기
kubectl	Kubernetes 관리 CLI	kubectl 설치하기
Docker	필요한 minikube 드라이버	Docker 시작하기

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이라는 두 개의 네임스페이스를 만들고 각 네임스페이스에 webapp 및 loadbalancer라는 두 개의 nginx 파드를 배포합니다. 새로운 리소스를 적용하십시오:

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 리소스가 있으므로 데모 클러스터에 Teleport Kubernetes 서비스를 설치하여 Kubernetes 사용자가 액세스할 수 있는 리소스를 더 잘 제어할 수 있습니다.

Teleport Helm 리포지토리를 설정하세요. Teleport Helm 리포지토리에 호스팅된 차트를 설치하도록 Helm을 허용하세요:

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

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

helm repo update

Kubernetes 서비스가 Teleport 클러스터에 참여하는 데 사용할 토큰을 요청하십시오:

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

이 토큰을 복사하여 Teleport Kubernetes 서비스를 실행할 때 사용할 수 있습니다.

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

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 16.2.0

이 helm install 명령은 곧 추가될 Kubernetes 서비스 인스턴스에 두 개의 레이블인 region:local 및 platform:minikube를 제공합니다. 우리는 이후 이 레이블을 사용하여 클러스터의 액세스 제어를 구성할 것입니다.

teleport 파드가 클러스터에서 실행되고 있는지 확인하십시오:

kubectl -n teleport-agent get pods

Teleport 클러스터에 Teleport Kubernetes 서비스가 등록되었는지 확인하려면 다음 명령을 실행하십시오:

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: 16.2.0
version: v3

2단계/3. Teleport 역할 정의하기

Teleport Kubernetes 서비스는 사용자의 요청을 Kubernetes API 서버로 프록시하기 위해 사용자의 역할을 조회합니다. 이 정보를 바탕으로 Kubernetes 서비스는 요청을 수락하거나 거부합니다.

유효한 요청에 대해 Kubernetes 서비스는 요청 헤더를 재작성하여 Teleport 사용자가 원하는 Kubernetes 사용자 및 그룹으로 가장하고, 이 요청을 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: 사용자를 developers라는 Kubernetes 그룹의 구성원으로 인증합니다. 이 그룹은 이전 안내서에서 pod-viewer Kubernetes Role과 연결했습니다.
kubernetes_users: 사용자를 기본 minikube 사용자로 인증합니다.

역할 생성하기

kube-access 역할 구성을 완료했으면 다음 명령을 사용하여 생성하십시오:

tctl create 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 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

github 인증 커넥터를 가져옵니다:
```
tctl get github/github --with-secrets > github.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.
github.yaml을 편집하고 teams_to_roles 섹션에 kube-access을 추가합니다.

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

여기에 예시가 있습니다:
```
  teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - kube-access
```
변경 사항을 적용합니다:
```
tctl create -f github.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

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 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

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 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

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 역할은 사용자를 developers Kubernetes 그룹에 매핑했으며, 이 그룹은 파드를 보기만 할 수 있는 권한을 가진 것을 확인하십시오:

kubectl auth can-i create pods
no

Teleport 역할 및 Kubernetes RBAC 리소스를 구성함으로써, 귀하의 조직 사용자들이 Kubernetes 기반 인프라에 접근하는 방식을 세세하게 조정할 수 있습니다.

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

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

minikube 클러스터에 대한 모든 제어를 복구하려면 기본 minikube 컨텍스트를 대신 사용할 수 있습니다:

kubectl config use-context minikube

다음 단계

Kubernetes에 대한 Teleport RBAC가 어떻게 작동하는지에 대한 보다 자세한 정보는 Kubernetes 액세스 제어 가이드를 참조하시기 바랍니다. 다양한 Teleport 및 Kubernetes RBAC 구성을 시도해 볼 수 있도록 minikube 클러스터를 계속 실행 상태로 둘 수 있습니다.

이제 Teleport의 RBAC 시스템을 구성하여 Kubernetes 클러스터에 대한 액세스를 제어하는 방법을 알고 있으므로 리소스 접근 요청과 액세스 요청 플러그인을 설정하여 원하는 커뮤니케이션 워크플로우에 따라 액세스를 관리하는 방법을 배워보세요.

Teleport 원문 보기