Kubernetes 접근 제어 설정
Teleport Kubernetes 서비스는 Kubernetes 사용자와 하나 이상의 Kubernetes 클러스터 사이에 위치하는 프록시입니다. 이 가이드에서는 로컬 Kubernetes 클러스터를 사용하여 Teleport의 역할 기반 접근 제어(RBAC) 시스템을 구성하고 Kubernetes 클러스터, 그룹, 사용자 및 리소스에 대한 접근을 관리하는 방법을 보여드립니다.
Teleport Kubernetes 서비스는 Kubernetes 사용자와 하나 이상의 Kubernetes 클러스터 사이에 위치하는 프록시입니다.
이 가이드에서는 로컬 Kubernetes 클러스터를 사용하여 Teleport의 역할 기반 접근 제어(RBAC) 시스템을 구성하고 Kubernetes 클러스터, 그룹, 사용자 및 리소스에 대한 접근을 관리하는 방법을 보여드립니다.
작동 방식#
사용자가 Teleport에 인증하면, Teleport Kubernetes 서비스를 통해 인가된 Kubernetes 클러스터에 요청을 보낼 수 있는 kubeconfig를 받게 됩니다. Kubernetes 서비스는 역할을 통해 Teleport 사용자에게 할당된 권한에 따라 이러한 요청을 검사, 수정 또는 거부할 수 있습니다.
사전 요구사항#
-
A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.
-
The
tctlandtshclients.Installing `tctl` and `tsh` clients
-
Determine the version of your Teleport cluster. The
tctlandtshclients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at/v1/webapi/findand use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:$ TELEPORT_DOMAIN= $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')" -
Follow the instructions for your platform to install
tctlandtshclients:
-
To check that you can connect to your Teleport cluster, sign in with tsh login, then
verify that you can run tctl commands using your current credentials.
For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:
$ tsh login --proxy= --user=
$ tctl status
# Cluster (=teleport.url=)
# Version (=teleport.version=)
# CA pin (=presets.ca_pin=)
If you can connect to the cluster and run the tctl status command, you can use your
current credentials to run subsequent tctl commands from your workstation.
If you host your own Teleport cluster, you can also run tctl commands on the computer that
hosts the Teleport Auth Service for full permissions.
로컬 데모 환경을 실행하려면 워크스테이션에 다음 도구들이 설치되어 있어야 합니다:
| 도구 | 목적 | 설치 링크 |
|---|---|---|
| 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 두 개의 네임스페이스를 생성하고 각각에 두 개의 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 서비스를 설치합니다.
Configure Helm to fetch Teleport charts from the Teleport Helm repository:
$ helm repo add teleport (=teleport.helm_repo_url=)
Refresh the local Helm cache by fetching the latest charts:
$ helm repo update
Kubernetes 서비스가 Teleport 클러스터에 조인하는 데 사용할 토큰을 요청합니다:
$ tctl tokens add --type=kube,app,discovery --ttl=1h --format=text
이 토큰을 복사하여 Teleport Kubernetes 서비스를 실행할 때 사용할 수 있도록 안전한 곳에 보관합니다.
Teleport Proxy 서비스의 호스트 및 포트를 에 할당하고(예: mytenant.teleport.sh:443), 앞에서 요청한 토큰을 에 할당하여 클러스터에 Teleport Kubernetes 서비스를 설치합니다:
$ helm install teleport-agent teleport/teleport-kube-agent \
--set kubeClusterName=minikube \
--set roles="kube\,app\,discovery" \
--set proxyAddr= \
--set authToken= \
--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-viewerKubernetesRole과 연결한 Kubernetes 그룹developers의 멤버로 사용자를 Kubernetes 클러스터에 인증합니다.kubernetes_users: 기본minikube사용자로 사용자를 Kubernetes 클러스터에 인증합니다.
역할 생성#
kube-access 역할 구성을 완료한 후 다음 명령으로 생성합니다:
$ tctl create kube-access.yaml
Assign the kube-access role to your Teleport user by running the appropriate
commands for your authentication provider:
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 시스템을 구성하는 방법을 배웠으니, 즉시 접근을 위한 리소스 접근 요청과 선택한 커뮤니케이션 워크플로로 접근을 관리하기 위한 접근 요청 플러그인 설정 방법을 알아보세요.
