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

Teleport Kubernetes 서비스는 Kubernetes 사용자와 하나 이상의 Kubernetes 클러스터 간의 프록시 역할을 합니다.

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

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

필수 조건

실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
tctl 관리자 도구와 tsh 클라이언트 도구.

tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하십시오.

연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  17.0.0-dev
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

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

도구	목적	설치 링크
minikube	로컬 Kubernetes 배포 도구	Install minikube
Helm	Kubernetes 패키지 관리자	Install Helm
kubectl	Kubernetes 관리자 CLI	Install kubectl
Docker	필요 minikube 드라이버	Get Started With 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 저장소를 설정합니다.

Helm이 Teleport 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 Proxy Service의 호스트 및 포트 (예: 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 17.0.0-dev

이 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: 17.0.0-dev
version: v3

2/3단계. Teleport 역할 정의

Teleport Kubernetes 서비스는 사용자의 역할을 확인하여 Teleport 사용자의 요청을 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 : 사용자를 Kubernetes 그룹 developers 의 일원으로 인증하며, 이 그룹은 이 가이드의 이전 섹션에서 pod-viewer Kubernetes Role 과 연결되었습니다.
kubernetes_users : 사용자를 기본 minikube 사용자로 Kubernetes 클러스터에 인증합니다.

역할 생성

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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

텍스트 편집기에서 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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

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는 클러스터에 연결하는 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 시스템을 구성하는 방법을 알게 되었으니, 즉시 접근을 위해 리소스 접근 요청과 선택한 커뮤니케이션 워크플로우로 접근을 관리할 수 있는 접근 요청 플러그인 설정 방법을 배워보세요.

Teleport 원문 보기