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

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      region: '*'
      environment: development
      # ...
  deny: {}

spec:
  allow:
    kubernetes_labels:
      '*': '*'
    # ...

spec:
  allow:
    kubernetes_labels:
      region: 'us-east-*'
      team: '^data-eng-[a-z-]+$'
    # ...

spec:
  allow:
    kubernetes_labels:
      region: 'us-east-*'
      environment: ['development', 'staging']
    # ...

$ helm upgrade teleport-agent teleport/teleport-kube-agent --set kubeClusterName=${CLUSTER?}\
  --set proxyAddr=${PROXY?} --set authToken=${TOKEN?} --create-namespace --namespace=teleport-agent\
  --set labels.env=prod --set labels.region=us-west-1

kubernetes_service:
  enabled: true
  kube_cluster_name: cookie
  labels:
    env: prod
    region: us-west-1

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_groups:
    - developers
    - viewers
    kubernetes_users:
    - myuser
    - system:serviceaccount:someNamespace:saName # 서비스 계정 이름
    # ...
  deny: {}

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-viewer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: cluster-viewer-group
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: cluster-viewer-user

system:serviceaccount:<namespace>:<service_account_name>

kind: role
metadata:
  name: kube-access-impersonate-sa
version: v7
spec:
  allow:
    kubernetes_users:
    - system:serviceaccount:someNamespace:saName
    # ...
  deny: {}

이는 사용자와 자동으로 임퍼소네이트된 그룹 모두의 결합된 권한을 갖게 되므로 혼란을
일으킬 수 있습니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: teleport-impersonation
rules:
- apiGroups:
  - ""
  resources:
  - users
  - groups
  - serviceaccounts
  verbs:
  - impersonate
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - "authorization.k8s.io"
  resources:
  - selfsubjectaccessreviews
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: teleport
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: teleport-impersonation
subjects:
- kind: ServiceAccount
  name: teleport-serviceaccount
  namespace: default

kind: role
version: v7
metadata:
  name: group-member
spec:
  allow:
    kubernetes_groups: ["{{external.groups}}"]
    kubernetes_users: ["{{external.kube_username}}"]
    # ...

kind: role
version: v7
metadata:
  name: group-member
spec:
  allow:
    kubernetes_groups: ["developers", "viewers"]
    kubernetes_users: ["myuser"]
    # ...

kind: role
version: v7
metadata:
  name: group-member
spec:
  allow:
    kubernetes_groups: ["{{external.groups}}"]
    kubernetes_users: ["{{external.kube_username}}"]
    # ...

kind: user
version: v2
metadata:
  name: alice
spec:
  roles:
    - group-member
  traits:
    groups:
      - developers
      - viewers
    kube_username:
      - myuser

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: pods
        api_group: ""
        namespace: production
        name: webapp
        verbs: ["*"]
      - kind: deployments
        api_group: apps
        namespace: development
        name: "*"
    # ...

$ kubectl api-resources --namespaced=true -o=name
$ kubectl api-resources --namespaced=false -o=name

• name: 접근을 허용할 파드의 이름입니다. kube-access에서는 webapp 파드입니다.

• verbs: 리소스에 허용할 작업입니다. 현재 Teleport는 다음을 지원합니다:

  Verb	부여하는 접근 권한
  *	모든 작업
  get	리소스 읽기
  list	리소스 목록 조회
  create	리소스 생성
  update	리소스 업데이트
  patch	리소스 패치
  delete	리소스 삭제
  deletecollection	리소스 컬렉션 삭제
  watch	리소스 감시
  portforward	파드에 대한 포트포워드 요청 생성
  exec	파드 내 명령 실행

namespace, name, api_group 필드에는 와일드카드 문자(*)를 추가하여 임의의 문자 시퀀스를 대체할 수 있습니다. 예를 들어, name: "pod-*-*"는 pod-1-a와 pod-2-c라는 이름의 파드와 일치합니다. kubernetes_labels와 마찬가지로, 값이 ^로 시작하고 $로 끝나면 Kubernetes 서비스는 이를 Go의 re2 구문을 사용하는 정규 표현식으로 처리합니다 (re2 README 참조).

역할 V7#

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: pod
        namespace: production
        name: webapp
        verbs: ["*"]
    # ...

• kind: 접근을 활성화할 리소스의 종류입니다. 현재 Teleport는 다음 종류를 지원합니다:

  Warning

* 종류의 동작은 이후 버전과 약간 다릅니다. V7에서는 namespace 필드와 관계없이 클러스터 범위 리소스를 포함한 모든 리소스에 대한 접근을 허용합니다. 이후 역할 버전에서는 namespace 필드가 강제되므로, 업그레이드할 때 특히 deny 쪽에서 리소스를 조정해야 할 수 있습니다.

• namespace: 리소스에 대한 접근을 허용할 Kubernetes 네임스페이스입니다. kube-access 역할에서는 production 네임스페이스의 파드에 대한 접근을 허용하고 있습니다. kind 필드가 *로 설정된 경우 namespace 필드는 무시되며, 이는 namespace 필드가 강제되는 이후 역할 버전과 다른 동작이라는 점에 유의하세요.

• name: 접근을 허용할 파드의 이름입니다. kube-access에서는 webapp 파드입니다.

• verbs: 리소스에 허용할 작업입니다. 현재 Teleport는 다음을 지원합니다:

  Verb	부여하는 접근 권한
  *	모든 작업
  get	리소스 읽기
  list	리소스 목록 조회
  create	리소스 생성
  update	리소스 업데이트
  patch	리소스 패치
  delete	리소스 삭제
  deletecollection	리소스 컬렉션 삭제
  watch	리소스 감시
  portforward	파드에 대한 포트포워드 요청 생성
  exec	파드 내 명령 실행

namespace와 name 필드 모두에 와일드카드 문자(*)를 추가하여 임의의 문자 시퀀스를 대체할 수 있습니다. 예를 들어, name: "pod-*-*"는 pod-1-a와 pod-2-c라는 이름의 파드와 일치합니다. kubernetes_labels와 마찬가지로, 값이 ^로 시작하고 $로 끝나면 Kubernetes 서비스는 이를 Go의 re2 구문을 사용하는 정규 표현식으로 처리합니다(re2 README 참조).

역할 V6#

kind: role
metadata:
  name: kube-access
version: v6
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: pod
        namespace: production
        name: webapp
    # ...

• kind: 접근을 활성화할 리소스의 종류입니다. 지원되는 유일한 값은 pod입니다.
• namespace: 리소스에 대한 접근을 허용할 Kubernetes 네임스페이스입니다. kube-access 역할에서는 production 네임스페이스의 파드에 대한 접근을 허용하고 있습니다.
• name: 접근을 허용할 파드의 이름입니다. kube-access에서는 webapp 파드입니다.

namespace와 name 필드 모두에 와일드카드 문자(*)를 추가하여 임의의 문자 시퀀스를 대체할 수 있습니다. 예를 들어, name: "pod-*-*"는 pod-1-a와 pod-2-c라는 이름의 파드와 일치합니다. kubernetes_labels와 마찬가지로, 값이 ^로 시작하고 $로 끝나면 Kubernetes 서비스는 이를 Go의 re2 구문을 사용하는 정규 표현식으로 처리합니다(re2 README 참조).

예시#

production을 제외한 네임스페이스가 지정된 리소스에 대한 전체 접근#

다음 역할은 production 네임스페이스를 제외한 모든 네임스페이스의 모든 네임스페이스가 지정된 리소스에 대한 전체 접근을 부여하며, production에서는 어떤 리소스에도 접근할 수 없습니다.

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # v7에서 namespace는 네임스페이스 내의 모든 것을 의미합니다.
      - kind: namespace  # v7은 단수형을 사용합니다.
        name: "*"
        verbs: ["*"]
  deny:
    kubernetes_resources:
      - kind: namespace  # v7은 단수형을 사용합니다.
        name: production
        verbs: ["*"]
    # ...

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # 모든 네임스페이스에서 네임스페이스가 지정된 리소스에 대한 접근을 부여합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: "^.+$"  # 네임스페이스가 지정된 모든 리소스와 일치하며, 클러스터 범위 리소스는 일치하지 않습니다.
        verbs: ["*"]
      # 네임스페이스 리소스 자체에 대한 접근을 부여합니다.
      - kind: namespaces  # v8에서 namespaces는 네임스페이스 자체를 의미합니다. 클러스터 범위 리소스로 간주되므로 별도로 추가해야 합니다.
        name: "*"
        verbs: ["*"]
  deny:
    kubernetes_resources:
      # production 네임스페이스의 네임스페이스가 지정된 리소스에 대한 접근을 거부합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: production
        verbs: ["*"]
      # 네임스페이스 리소스 자체에 대한 접근을 거부합니다.
      - kind: namespaces  # v8은 복수형을 사용합니다.
        name: production
        verbs: ["*"]
    # ...

또는 다음과 같이 사용할 수도 있습니다:

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # 모든 항목에 대한 전체 접근을 부여합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: "*"  # v8에서 '*'는 네임스페이스가 지정된 리소스와 클러스터 범위 리소스 모두와 일치합니다.
        verbs: ["*"]
  deny:
    kubernetes_resources:
      # 클러스터 범위 리소스에 대한 접근을 거부합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: ""  # 빈 네임스페이스는 클러스터 범위 리소스만 일치함을 의미합니다.
        verbs: ["*"]
      # production 네임스페이스의 네임스페이스가 지정된 리소스에 대한 접근을 거부합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: production
        verbs: ["*"]
      # 네임스페이스 리소스 자체에 대한 접근을 거부합니다.
      - kind: namespaces  # v8은 복수형을 사용합니다.
        name: production
        verbs: ["*"]
    # ...

dev 네임스페이스와 clusterroles를 제외한 모든 클러스터 범위 리소스에 대한 전체 접근#

다음 역할은 dev 네임스페이스의 모든 리소스와 clusterroles를 제외한 모든 클러스터 범위 리소스에 대한 접근을 부여합니다.

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # v7에서 "*"는 네임스페이스와 관계없이 클러스터 범위 리소스를 포함합니다.
      - kind: "*"
        name: "*"
        namespace: dev
        verbs: ["*"]
  deny:
    kubernetes_resources:
      - kind: clusterrole  # v7은 단수형을 사용합니다.
        name: "*"
        verbs: ["*"]
    # ...

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # dev 네임스페이스의 모든 리소스에 대한 접근을 부여합니다.
      # v8에서는 네임스페이스가 설정된 경우 "*"에 클러스터 범위 리소스가 포함되지 않습니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: dev
        verbs: ["*"]
      # 모든 클러스터 범위 리소스에 대한 접근을 부여합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: ""  # 빈 네임스페이스는 클러스터 범위 리소스만 일치함을 의미합니다.
        verbs: ["*"]
  deny:
    kubernetes_resources:
      - kind: clusterroles  # v8은 복수형을 사용합니다.
        api_group: "*"
        name: "*"
    # ...

모든 항목에 대한 전체 접근#

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: "*"
        name: "*"
        namespace: "*"
        verbs: ["*"]
    # ...

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: "*"  # 와일드카드 '*'는 네임스페이스가 지정된 리소스와 클러스터 범위 리소스 모두와 일치합니다.
        verbs: ["*"]
    # ...

Kubernetes 서비스가 Teleport 역할을 평가하는 방식#

Teleport 사용자가 Kubernetes 클러스터의 API 서버에 요청을 보내면, Teleport Kubernetes 서비스는 요청을 가로채고 사용자의 인가를 검사합니다. 사용자가 특정 리소스를 볼 권한이 없는 경우 Kubernetes 서비스는 요청을 거부합니다. 사용자가 요청을 수행할 권한이 있는 경우, Kubernetes 서비스는 요청을 수정하여 적절한 API 서버로 전달합니다.

사용자 요청 인가#

Teleport Kubernetes 서비스는 요청을 받으면 사용자 역할 내의 두 필드를 평가합니다. 이러한 필드 중 하나라도 사용자가 요청을 수행하도록 허용하지 않으면, Kubernetes 서비스는 사용자에게 오류를 반환합니다:

kubernetes_labels#

Teleport Kubernetes 서비스는 파드가 실행 중인 클러스터에 사용자의 kubernetes_labels 구성과 일치하는 라벨이 있는 경우에만 파드에 대한 접근을 허용합니다.

kubernetes_resources#

Kubernetes API 서버 내의 일부 리소스 URI에는 특정 리소스의 이름이 포함됩니다.

예를 들어, 사용자가 kubectl exec를 실행하여 development 네임스페이스의 webapp 파드에 대해 명령을 실행하면, kubectl은 대상 클러스터의 API 서버에 다음 경로로 요청을 보냅니다:

"/api/v1/namespaces/development/pods/webapp/exec"

Kubernetes API 서버에 대한 요청의 URL 경로 내에 Kubernetes 파드가 있는 경우, Teleport Kubernetes 서비스는 사용자가 해당 파드에 접근할 권한이 있는지 확인합니다.

위 예시에서 Kubernetes 서비스는 사용자가 development 네임스페이스의 webapp 파드에 접근할 권한이 있는지 확인하고, 없으면 요청을 거부합니다.

사용자 요청 전달#

Teleport Kubernetes 서비스가 사용자가 Kubernetes 클러스터와 (해당하는 경우) 특정 리소스에 대해 요청을 수행할 권한이 있다고 인가하면, 상위 API 서버에 대한 요청을 조립합니다. 사용자 역할의 kubernetes_groups와 kubernetes_users 필드(앞서 설명한 이 필드에 대한 설명 참조)를 기반으로 요청에 임퍼소네이션 헤더를 추가합니다.

Teleport Kubernetes 서비스는 Teleport 사용자의 kubernetes_groups와 kubernetes_users 필드에 나열된 RBAC 프린시펄을 통해 상위 API 서버에 접근하므로, 이러한 필드에 지정하는 프린시펄은 사용자의 kubernetes_resources 필드에 나열된 리소스에 대한 접근 권한을 가지고 있어야 합니다. 그렇지 않으면 Kubernetes 서비스는 부적절한 인가로 요청을 상위 API 서버에 전달하게 되고, API 서버는 요청을 거부합니다.

여러 역할#

Kubernetes 서비스가 여러 역할을 평가하는 방식#

Teleport Kubernetes 서비스는 사용자의 Kubernetes API 서버에 대한 요청을 평가하기 전에 사용자의 각 역할을 확인합니다. 한 역할의 spec.allow.kubernetes_labels 또는 spec.allow.kubernetes_resources 조건이 사용자의 요청과 일치하지 않으면, Kubernetes 서비스는 다음 역할을 확인하며, 이런 식으로 계속됩니다.

Kubernetes 서비스가 클러스터의 모든 라벨과 요청의 리소스와 일치하는 spec.allow 조건을 가진 역할을 찾으면, 해당 역할의 allow.kubernetes_groups와 allow.kubernetes_users 필드를 조회합니다. 이후 임퍼소네이션 헤더를 작성하는 데 사용할 RBAC 프린시펄 목록에 이러한 값을 추가합니다.

다음으로 Kubernetes 서비스는 사용자의 각 역할에서 spec.deny 조건을 확인합니다. 한 역할의 spec.deny.kubernetes_labels 또는 spec.deny.kubernetes_resources 필드가 사용자의 요청과 일치하면, Kubernetes 서비스는 해당 역할의 spec.deny.kubernetes_groups와 spec.deny.kubernetes_users 필드를 조회합니다. 이전에 생성한 사용자와 그룹 목록에서 이러한 값을 각각 제거하여, 사용자가 이러한 RBAC 프린시펄에 접근하지 못하도록 거부합니다.

예시#

사용자에게 다음 세 가지 역할이 할당되어 있다고 가정해 보겠습니다:

kind: role
metadata:
  name: allow-dev-us-east-2
version: v7
spec:
  allow:
    kubernetes_labels:
      "region": "us-east-2"
    kubernetes_resources:
      - kind: pod
        namespace: "development"
        name: "redis-*"
      - kind: pod
        namespace: "development"
        name: "nginx-*"
    kubernetes_groups:
      - dev-viewers # 사용자가 development 네임스페이스에서 파드를 볼 수 있도록 허용합니다
---
kind: role
metadata:
  name: allow-exec
version: v7
spec:
  allow:
    kubernetes_labels:
        "*": "*"
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"
    kubernetes_groups:
      - executors # 사용자가 모든 파드에 대해 명령을 실행할 수 있도록 허용합니다
---
kind: role
metadata:
  name: deny-redis-exec
version: v7
spec:
  deny:
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "redis-*"
    kubernetes_groups:
      - executors

dev-viewers Kubernetes 그룹은 사용자가 development 네임스페이스의 파드를 볼 수 있도록 허용합니다. executors Kubernetes 그룹은 사용자가 모든 네임스페이스의 모든 파드에 대해 명령을 실행할 수 있도록 허용합니다.

이러한 역할을 가진 사용자가 development 네임스페이스에서 kubectl get pods/redis-1을 실행하고 클러스터에 region:us-east-2 라벨이 있는 경우, Kubernetes 서비스는 요청을 수락합니다. deny-redis-exec 역할이 redis-* 파드에 대해 executors 그룹을 거부하기 때문에, Kubernetes 서비스는 dev-viewers 그룹은 임퍼소네이트하지만 executors 그룹은 임퍼소네이트하지 않은 상태로 요청을 전달합니다.

그러나 동일한 사용자가 동일한 클러스터에 대해 development 네임스페이스에서 kubectl exec -it nginx /bin/bash를 실행하면, deny-redis-exec 역할의 deny 조건이 요청과 일치하지 않으므로 Kubernetes 서비스는 dev-viewers와 executors 그룹 모두에 대한 임퍼소네이션 헤더로 요청을 전달합니다.

리소스에 대한 접근을 점진적으로 활성화#

Teleport와 Kubernetes RBAC를 설계하여 제한된 Kubernetes 리소스 부분 집합에 대한 접근을 점진적으로 허용할 수 있습니다. 다시 말해, 사용자는 Kubernetes 클러스터의 광범위한 리소스에 제한된 접근 권한을 갖게 됩니다. 이러한 사용자의 부분 집합은 더 제한된 리소스 집합에 더 큰 접근 권한을 갖게 됩니다. 이러한 사용자의 부분 집합 중에서, 다른 리소스 집합에 대해 더 작은 그룹에 더 큰 접근 권한을 할당할 수 있으며, 이런 식으로 계속됩니다.

이를 위해 다음과 같은 여러 Teleport 역할을 정의합니다:

• 일부 역할은 더 많은 Kubernetes 리소스에 대해 낮은 수준의 접근을 활성화합니다
• 다른 역할은 더 적은 Kubernetes 리소스에 대해 더 높은 수준의 접근을 허용합니다

그런 다음 서로 다른 사용자에게 역할의 조합을 할당할 수 있습니다.

예를 들어, 다음 역할 조합은 사용자가 등록된 모든 Kubernetes 클러스터에서 모든 파드를 볼 수 있도록 허용하지만, nginx-* 파드에서만 kubectl exec 또는 kubectl logs를 실행할 수 있도록 합니다:

kind: role
metadata:
  name: kube-viewer
version: v7
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"
    kubernetes_groups:
    - viewer # 파드를 가져오고 목록을 조회할 수 있지만 명령 실행이나 로그 검색은 할 수 없습니다
---
kind: role
metadata:
  name: nginx-exec
version: v7
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "nginx-*"
    kubernetes_groups:
    - execAndLogs

이 경우, kube-viewer 역할은 사용자를 Kubernetes viewer 그룹에 매핑하여, 사용자가 파드를 가져오고 목록을 조회할 수 있지만 명령을 실행하거나 로그를 검색할 수는 없도록 합니다. nginx-exec 역할을 사용하면, 사용자는 명령을 실행하고 로그를 검색할 수 있는 execAndLogs 그룹에 접근할 수 있지만, nginx 파드에서만 가능합니다.

이 설정에서는 Teleport 사용자의 요구 사항에 따라 kube-viewer 역할을 파드의 부분 집합에 대한 상승된 접근 권한을 부여하는 다른 역할과 결합할 수도 있습니다.

보안 고려 사항: 리소스 네임스페이스 제한#

Teleport 사용자가 예를 들어 kubectl get pods로 파드 목록 조회 요청을 보내면, Teleport Kubernetes 서비스는 다음을 수행합니다:

• 사용자의 Teleport 역할을 기반으로 임퍼소네이션 헤더를 요청에 추가하여 상위 Kubernetes API 서버에서 사용 가능한 파드를 가져옵니다. 여기에는 사용자가 요청을 보낼 때 사용하는 Kubernetes 사용자와 그룹이 포함됩니다.
• kubernetes_resources를 통해 사용자가 접근할 권한이 있는 파드를 기준으로 사용 가능한 파드 목록을 필터링합니다.
• 파드 목록을 사용자에게 반환합니다.

의도치 않게 리소스가 유출되는 것을 방지하려면, Kubernetes RBAC의 네임스페이스 제한이 Teleport에 설정한 제한과 일치하는지 확인해야 합니다.

예를 들어, 사용자가 어떤 네임스페이스의 어떤 파드에도 접근을 허용하는 Teleport 역할을 가지고 있고, 해당 사용자를 default-pod-viewer Kubernetes 그룹에 매핑한다고 가정해 보겠습니다. 이 그룹은 default 네임스페이스의 파드만 볼 수 있습니다:

kind: role
metadata:
  name: kube-access-1
version: v7
spec:
  allow:
    kubernetes_groups:
      - default-pod-viewer
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"
    # ...

사용자는 두 번째 Teleport 역할을 가지고 있으며, 이는 사용자를 system:masters Kubernetes 그룹(모든 네임스페이스의 모든 파드에 접근 가능)에 매핑하고, default 네임스페이스의 webapp 파드에만 접근 권한을 부여합니다:

metadata:
  name: kube-access-2
version: v7
spec:
  allow:
    kubernetes_groups:
      - system:masters
    kubernetes_resources:
      - kind: pod
        namespace: "default"
        name: "webapp"
    # ...

kube-access-2 역할이 사용자를 system:masters에 매핑하므로, Kubernetes 서비스가 이 사용자로부터 요청을 전달할 때 요청의 임퍼소네이션 헤더에 system:masters 그룹을 추가하여 Kubernetes 클러스터에서 모든 파드를 가져옵니다.

그러나 사용자는 모든 네임스페이스의 모든 파드에 대한 접근을 허용하는 역할(kube-access-1)도 가지고 있으므로, Kubernetes 서비스는 API 서버에 대한 첫 번째 요청을 통해 가져온 파드를 필터링하지 않습니다.

즉, Kubernetes 서비스는 Teleport가 default 네임스페이스의 webapp 파드에만 접근을 허용하기 위해 사용자를 system:masters 그룹에 매핑했다는 것을 알 방법이 없습니다.

Teleport RBAC에 네임스페이스 제한이 있는 경우, Teleport 사용자에게 매핑하는 Kubernetes RBAC 리소스에도 동일한 네임스페이스 제한이 있는지 확인해야 합니다.

예를 들어, 다음과 같은 권한을 갖도록 kube-access-1 역할을 다시 작성하여 사용자를 default 네임스페이스의 파드로 제한해야 합니다:

kind: role
metadata:
  name: kube-access-1
version: v7
spec:
  allow:
    kubernetes_groups:
      - default-pod-viewer
    kubernetes_resources:
      - kind: pod
        namespace: "default"
        name: "*"
    # ...

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

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      region: '*'
      environment: development
      # ...
  deny: {}

spec:
  allow:
    kubernetes_labels:
      '*': '*'
    # ...

spec:
  allow:
    kubernetes_labels:
      region: 'us-east-*'
      team: '^data-eng-[a-z-]+$'
    # ...

spec:
  allow:
    kubernetes_labels:
      region: 'us-east-*'
      environment: ['development', 'staging']
    # ...

$ helm upgrade teleport-agent teleport/teleport-kube-agent --set kubeClusterName=${CLUSTER?}\
  --set proxyAddr=${PROXY?} --set authToken=${TOKEN?} --create-namespace --namespace=teleport-agent\
  --set labels.env=prod --set labels.region=us-west-1

kubernetes_service:
  enabled: true
  kube_cluster_name: cookie
  labels:
    env: prod
    region: us-west-1

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_groups:
    - developers
    - viewers
    kubernetes_users:
    - myuser
    - system:serviceaccount:someNamespace:saName # 서비스 계정 이름
    # ...
  deny: {}

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-viewer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: cluster-viewer-group
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: cluster-viewer-user

system:serviceaccount:<namespace>:<service_account_name>

kind: role
metadata:
  name: kube-access-impersonate-sa
version: v7
spec:
  allow:
    kubernetes_users:
    - system:serviceaccount:someNamespace:saName
    # ...
  deny: {}

이는 사용자와 자동으로 임퍼소네이트된 그룹 모두의 결합된 권한을 갖게 되므로 혼란을
일으킬 수 있습니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: teleport-impersonation
rules:
- apiGroups:
  - ""
  resources:
  - users
  - groups
  - serviceaccounts
  verbs:
  - impersonate
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - "authorization.k8s.io"
  resources:
  - selfsubjectaccessreviews
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: teleport
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: teleport-impersonation
subjects:
- kind: ServiceAccount
  name: teleport-serviceaccount
  namespace: default

kind: role
version: v7
metadata:
  name: group-member
spec:
  allow:
    kubernetes_groups: ["{{external.groups}}"]
    kubernetes_users: ["{{external.kube_username}}"]
    # ...

kind: role
version: v7
metadata:
  name: group-member
spec:
  allow:
    kubernetes_groups: ["developers", "viewers"]
    kubernetes_users: ["myuser"]
    # ...

kind: role
version: v7
metadata:
  name: group-member
spec:
  allow:
    kubernetes_groups: ["{{external.groups}}"]
    kubernetes_users: ["{{external.kube_username}}"]
    # ...

kind: user
version: v2
metadata:
  name: alice
spec:
  roles:
    - group-member
  traits:
    groups:
      - developers
      - viewers
    kube_username:
      - myuser

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: pods
        api_group: ""
        namespace: production
        name: webapp
        verbs: ["*"]
      - kind: deployments
        api_group: apps
        namespace: development
        name: "*"
    # ...

$ kubectl api-resources --namespaced=true -o=name
$ kubectl api-resources --namespaced=false -o=name

• api_group: 리소스의 API 그룹입니다. 위의 예시 kube-access에서, pods 리소스는 핵심 리소스이므로 api_group 값은 ""이고, deployments 리소스 종류에는 apps로 값이 설정되어 있습니다. 와일드카드를 사용하여 모든 API 그룹과 일치시킬 수 있습니다.

• namespace: 리소스에 대한 접근을 허용할 Kubernetes 네임스페이스입니다. 클러스터 범위 리소스의 경우 비어 있거나 *여야 합니다. 다른 와일드카드를 포함한 다른 값은 네임스페이스가 지정된 리소스와만 일치합니다. kube-access 역할에서는 production 네임스페이스의 파드에 대한 접근을 허용하고 있습니다.

  Tip

와일드카드 *를 사용하면 클러스터 범위 리소스를 포함하여(종류/api_group 기준) 모든 리소스와 일치한다는 점에 유의하세요. 빈 문자열 ""을 사용하면 클러스터 범위 리소스와만 일치합니다. ^.+$와 같은 다른 값은 네임스페이스가 지정된 리소스와만 일치하고 클러스터 범위 리소스는 제외합니다.

• name: 접근을 허용할 파드의 이름입니다. kube-access에서는 webapp 파드입니다.

• verbs: 리소스에 허용할 작업입니다. 현재 Teleport는 다음을 지원합니다:

  Verb	부여하는 접근 권한
  *	모든 작업
  get	리소스 읽기
  list	리소스 목록 조회
  create	리소스 생성
  update	리소스 업데이트
  patch	리소스 패치
  delete	리소스 삭제
  deletecollection	리소스 컬렉션 삭제
  watch	리소스 감시
  portforward	파드에 대한 포트포워드 요청 생성
  exec	파드 내 명령 실행

namespace, name, api_group 필드에는 와일드카드 문자(*)를 추가하여 임의의 문자 시퀀스를 대체할 수 있습니다. 예를 들어, name: "pod-*-*"는 pod-1-a와 pod-2-c라는 이름의 파드와 일치합니다. kubernetes_labels와 마찬가지로, 값이 ^로 시작하고 $로 끝나면 Kubernetes 서비스는 이를 Go의 re2 구문을 사용하는 정규 표현식으로 처리합니다 (re2 README 참조).

역할 V7#

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: pod
        namespace: production
        name: webapp
        verbs: ["*"]
    # ...

• kind: 접근을 활성화할 리소스의 종류입니다. 현재 Teleport는 다음 종류를 지원합니다:

  Warning

* 종류의 동작은 이후 버전과 약간 다릅니다. V7에서는 namespace 필드와 관계없이 클러스터 범위 리소스를 포함한 모든 리소스에 대한 접근을 허용합니다. 이후 역할 버전에서는 namespace 필드가 강제되므로, 업그레이드할 때 특히 deny 쪽에서 리소스를 조정해야 할 수 있습니다.

• namespace: 리소스에 대한 접근을 허용할 Kubernetes 네임스페이스입니다. kube-access 역할에서는 production 네임스페이스의 파드에 대한 접근을 허용하고 있습니다. kind 필드가 *로 설정된 경우 namespace 필드는 무시되며, 이는 namespace 필드가 강제되는 이후 역할 버전과 다른 동작이라는 점에 유의하세요.

• name: 접근을 허용할 파드의 이름입니다. kube-access에서는 webapp 파드입니다.

• verbs: 리소스에 허용할 작업입니다. 현재 Teleport는 다음을 지원합니다:

  Verb	부여하는 접근 권한
  *	모든 작업
  get	리소스 읽기
  list	리소스 목록 조회
  create	리소스 생성
  update	리소스 업데이트
  patch	리소스 패치
  delete	리소스 삭제
  deletecollection	리소스 컬렉션 삭제
  watch	리소스 감시
  portforward	파드에 대한 포트포워드 요청 생성
  exec	파드 내 명령 실행

namespace와 name 필드 모두에 와일드카드 문자(*)를 추가하여 임의의 문자 시퀀스를 대체할 수 있습니다. 예를 들어, name: "pod-*-*"는 pod-1-a와 pod-2-c라는 이름의 파드와 일치합니다. kubernetes_labels와 마찬가지로, 값이 ^로 시작하고 $로 끝나면 Kubernetes 서비스는 이를 Go의 re2 구문을 사용하는 정규 표현식으로 처리합니다(re2 README 참조).

역할 V6#

kind: role
metadata:
  name: kube-access
version: v6
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: pod
        namespace: production
        name: webapp
    # ...

• kind: 접근을 활성화할 리소스의 종류입니다. 지원되는 유일한 값은 pod입니다.
• namespace: 리소스에 대한 접근을 허용할 Kubernetes 네임스페이스입니다. kube-access 역할에서는 production 네임스페이스의 파드에 대한 접근을 허용하고 있습니다.
• name: 접근을 허용할 파드의 이름입니다. kube-access에서는 webapp 파드입니다.

namespace와 name 필드 모두에 와일드카드 문자(*)를 추가하여 임의의 문자 시퀀스를 대체할 수 있습니다. 예를 들어, name: "pod-*-*"는 pod-1-a와 pod-2-c라는 이름의 파드와 일치합니다. kubernetes_labels와 마찬가지로, 값이 ^로 시작하고 $로 끝나면 Kubernetes 서비스는 이를 Go의 re2 구문을 사용하는 정규 표현식으로 처리합니다(re2 README 참조).

예시#

production을 제외한 네임스페이스가 지정된 리소스에 대한 전체 접근#

다음 역할은 production 네임스페이스를 제외한 모든 네임스페이스의 모든 네임스페이스가 지정된 리소스에 대한 전체 접근을 부여하며, production에서는 어떤 리소스에도 접근할 수 없습니다.

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # v7에서 namespace는 네임스페이스 내의 모든 것을 의미합니다.
      - kind: namespace  # v7은 단수형을 사용합니다.
        name: "*"
        verbs: ["*"]
  deny:
    kubernetes_resources:
      - kind: namespace  # v7은 단수형을 사용합니다.
        name: production
        verbs: ["*"]
    # ...

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # 모든 네임스페이스에서 네임스페이스가 지정된 리소스에 대한 접근을 부여합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: "^.+$"  # 네임스페이스가 지정된 모든 리소스와 일치하며, 클러스터 범위 리소스는 일치하지 않습니다.
        verbs: ["*"]
      # 네임스페이스 리소스 자체에 대한 접근을 부여합니다.
      - kind: namespaces  # v8에서 namespaces는 네임스페이스 자체를 의미합니다. 클러스터 범위 리소스로 간주되므로 별도로 추가해야 합니다.
        name: "*"
        verbs: ["*"]
  deny:
    kubernetes_resources:
      # production 네임스페이스의 네임스페이스가 지정된 리소스에 대한 접근을 거부합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: production
        verbs: ["*"]
      # 네임스페이스 리소스 자체에 대한 접근을 거부합니다.
      - kind: namespaces  # v8은 복수형을 사용합니다.
        name: production
        verbs: ["*"]
    # ...

또는 다음과 같이 사용할 수도 있습니다:

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # 모든 항목에 대한 전체 접근을 부여합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: "*"  # v8에서 '*'는 네임스페이스가 지정된 리소스와 클러스터 범위 리소스 모두와 일치합니다.
        verbs: ["*"]
  deny:
    kubernetes_resources:
      # 클러스터 범위 리소스에 대한 접근을 거부합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: ""  # 빈 네임스페이스는 클러스터 범위 리소스만 일치함을 의미합니다.
        verbs: ["*"]
      # production 네임스페이스의 네임스페이스가 지정된 리소스에 대한 접근을 거부합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: production
        verbs: ["*"]
      # 네임스페이스 리소스 자체에 대한 접근을 거부합니다.
      - kind: namespaces  # v8은 복수형을 사용합니다.
        name: production
        verbs: ["*"]
    # ...

dev 네임스페이스와 clusterroles를 제외한 모든 클러스터 범위 리소스에 대한 전체 접근#

다음 역할은 dev 네임스페이스의 모든 리소스와 clusterroles를 제외한 모든 클러스터 범위 리소스에 대한 접근을 부여합니다.

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # v7에서 "*"는 네임스페이스와 관계없이 클러스터 범위 리소스를 포함합니다.
      - kind: "*"
        name: "*"
        namespace: dev
        verbs: ["*"]
  deny:
    kubernetes_resources:
      - kind: clusterrole  # v7은 단수형을 사용합니다.
        name: "*"
        verbs: ["*"]
    # ...

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      # dev 네임스페이스의 모든 리소스에 대한 접근을 부여합니다.
      # v8에서는 네임스페이스가 설정된 경우 "*"에 클러스터 범위 리소스가 포함되지 않습니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: dev
        verbs: ["*"]
      # 모든 클러스터 범위 리소스에 대한 접근을 부여합니다.
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: ""  # 빈 네임스페이스는 클러스터 범위 리소스만 일치함을 의미합니다.
        verbs: ["*"]
  deny:
    kubernetes_resources:
      - kind: clusterroles  # v8은 복수형을 사용합니다.
        api_group: "*"
        name: "*"
    # ...

모든 항목에 대한 전체 접근#

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: "*"
        name: "*"
        namespace: "*"
        verbs: ["*"]
    # ...

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      "*": "*"
    kubernetes_resources:
      - kind: "*"
        api_group: "*"
        name: "*"
        namespace: "*"  # 와일드카드 '*'는 네임스페이스가 지정된 리소스와 클러스터 범위 리소스 모두와 일치합니다.
        verbs: ["*"]
    # ...

Kubernetes 서비스가 Teleport 역할을 평가하는 방식#

Teleport 사용자가 Kubernetes 클러스터의 API 서버에 요청을 보내면, Teleport Kubernetes 서비스는 요청을 가로채고 사용자의 인가를 검사합니다. 사용자가 특정 리소스를 볼 권한이 없는 경우 Kubernetes 서비스는 요청을 거부합니다. 사용자가 요청을 수행할 권한이 있는 경우, Kubernetes 서비스는 요청을 수정하여 적절한 API 서버로 전달합니다.

사용자 요청 인가#

Teleport Kubernetes 서비스는 요청을 받으면 사용자 역할 내의 두 필드를 평가합니다. 이러한 필드 중 하나라도 사용자가 요청을 수행하도록 허용하지 않으면, Kubernetes 서비스는 사용자에게 오류를 반환합니다:

kubernetes_labels#

Teleport Kubernetes 서비스는 파드가 실행 중인 클러스터에 사용자의 kubernetes_labels 구성과 일치하는 라벨이 있는 경우에만 파드에 대한 접근을 허용합니다.

kubernetes_resources#

Kubernetes API 서버 내의 일부 리소스 URI에는 특정 리소스의 이름이 포함됩니다.

예를 들어, 사용자가 kubectl exec를 실행하여 development 네임스페이스의 webapp 파드에 대해 명령을 실행하면, kubectl은 대상 클러스터의 API 서버에 다음 경로로 요청을 보냅니다:

"/api/v1/namespaces/development/pods/webapp/exec"

Kubernetes API 서버에 대한 요청의 URL 경로 내에 Kubernetes 파드가 있는 경우, Teleport Kubernetes 서비스는 사용자가 해당 파드에 접근할 권한이 있는지 확인합니다.

위 예시에서 Kubernetes 서비스는 사용자가 development 네임스페이스의 webapp 파드에 접근할 권한이 있는지 확인하고, 없으면 요청을 거부합니다.

사용자 요청 전달#

Teleport Kubernetes 서비스가 사용자가 Kubernetes 클러스터와 (해당하는 경우) 특정 리소스에 대해 요청을 수행할 권한이 있다고 인가하면, 상위 API 서버에 대한 요청을 조립합니다. 사용자 역할의 kubernetes_groups와 kubernetes_users 필드(앞서 설명한 이 필드에 대한 설명 참조)를 기반으로 요청에 임퍼소네이션 헤더를 추가합니다.

Teleport Kubernetes 서비스는 Teleport 사용자의 kubernetes_groups와 kubernetes_users 필드에 나열된 RBAC 프린시펄을 통해 상위 API 서버에 접근하므로, 이러한 필드에 지정하는 프린시펄은 사용자의 kubernetes_resources 필드에 나열된 리소스에 대한 접근 권한을 가지고 있어야 합니다. 그렇지 않으면 Kubernetes 서비스는 부적절한 인가로 요청을 상위 API 서버에 전달하게 되고, API 서버는 요청을 거부합니다.

여러 역할#

Kubernetes 서비스가 여러 역할을 평가하는 방식#

Teleport Kubernetes 서비스는 사용자의 Kubernetes API 서버에 대한 요청을 평가하기 전에 사용자의 각 역할을 확인합니다. 한 역할의 spec.allow.kubernetes_labels 또는 spec.allow.kubernetes_resources 조건이 사용자의 요청과 일치하지 않으면, Kubernetes 서비스는 다음 역할을 확인하며, 이런 식으로 계속됩니다.

Kubernetes 서비스가 클러스터의 모든 라벨과 요청의 리소스와 일치하는 spec.allow 조건을 가진 역할을 찾으면, 해당 역할의 allow.kubernetes_groups와 allow.kubernetes_users 필드를 조회합니다. 이후 임퍼소네이션 헤더를 작성하는 데 사용할 RBAC 프린시펄 목록에 이러한 값을 추가합니다.

다음으로 Kubernetes 서비스는 사용자의 각 역할에서 spec.deny 조건을 확인합니다. 한 역할의 spec.deny.kubernetes_labels 또는 spec.deny.kubernetes_resources 필드가 사용자의 요청과 일치하면, Kubernetes 서비스는 해당 역할의 spec.deny.kubernetes_groups와 spec.deny.kubernetes_users 필드를 조회합니다. 이전에 생성한 사용자와 그룹 목록에서 이러한 값을 각각 제거하여, 사용자가 이러한 RBAC 프린시펄에 접근하지 못하도록 거부합니다.

예시#

사용자에게 다음 세 가지 역할이 할당되어 있다고 가정해 보겠습니다:

kind: role
metadata:
  name: allow-dev-us-east-2
version: v7
spec:
  allow:
    kubernetes_labels:
      "region": "us-east-2"
    kubernetes_resources:
      - kind: pod
        namespace: "development"
        name: "redis-*"
      - kind: pod
        namespace: "development"
        name: "nginx-*"
    kubernetes_groups:
      - dev-viewers # 사용자가 development 네임스페이스에서 파드를 볼 수 있도록 허용합니다
---
kind: role
metadata:
  name: allow-exec
version: v7
spec:
  allow:
    kubernetes_labels:
        "*": "*"
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"
    kubernetes_groups:
      - executors # 사용자가 모든 파드에 대해 명령을 실행할 수 있도록 허용합니다
---
kind: role
metadata:
  name: deny-redis-exec
version: v7
spec:
  deny:
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "redis-*"
    kubernetes_groups:
      - executors

dev-viewers Kubernetes 그룹은 사용자가 development 네임스페이스의 파드를 볼 수 있도록 허용합니다. executors Kubernetes 그룹은 사용자가 모든 네임스페이스의 모든 파드에 대해 명령을 실행할 수 있도록 허용합니다.

이러한 역할을 가진 사용자가 development 네임스페이스에서 kubectl get pods/redis-1을 실행하고 클러스터에 region:us-east-2 라벨이 있는 경우, Kubernetes 서비스는 요청을 수락합니다. deny-redis-exec 역할이 redis-* 파드에 대해 executors 그룹을 거부하기 때문에, Kubernetes 서비스는 dev-viewers 그룹은 임퍼소네이트하지만 executors 그룹은 임퍼소네이트하지 않은 상태로 요청을 전달합니다.

그러나 동일한 사용자가 동일한 클러스터에 대해 development 네임스페이스에서 kubectl exec -it nginx /bin/bash를 실행하면, deny-redis-exec 역할의 deny 조건이 요청과 일치하지 않으므로 Kubernetes 서비스는 dev-viewers와 executors 그룹 모두에 대한 임퍼소네이션 헤더로 요청을 전달합니다.

리소스에 대한 접근을 점진적으로 활성화#

Teleport와 Kubernetes RBAC를 설계하여 제한된 Kubernetes 리소스 부분 집합에 대한 접근을 점진적으로 허용할 수 있습니다. 다시 말해, 사용자는 Kubernetes 클러스터의 광범위한 리소스에 제한된 접근 권한을 갖게 됩니다. 이러한 사용자의 부분 집합은 더 제한된 리소스 집합에 더 큰 접근 권한을 갖게 됩니다. 이러한 사용자의 부분 집합 중에서, 다른 리소스 집합에 대해 더 작은 그룹에 더 큰 접근 권한을 할당할 수 있으며, 이런 식으로 계속됩니다.

이를 위해 다음과 같은 여러 Teleport 역할을 정의합니다:

• 일부 역할은 더 많은 Kubernetes 리소스에 대해 낮은 수준의 접근을 활성화합니다
• 다른 역할은 더 적은 Kubernetes 리소스에 대해 더 높은 수준의 접근을 허용합니다

그런 다음 서로 다른 사용자에게 역할의 조합을 할당할 수 있습니다.

예를 들어, 다음 역할 조합은 사용자가 등록된 모든 Kubernetes 클러스터에서 모든 파드를 볼 수 있도록 허용하지만, nginx-* 파드에서만 kubectl exec 또는 kubectl logs를 실행할 수 있도록 합니다:

kind: role
metadata:
  name: kube-viewer
version: v7
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"
    kubernetes_groups:
    - viewer # 파드를 가져오고 목록을 조회할 수 있지만 명령 실행이나 로그 검색은 할 수 없습니다
---
kind: role
metadata:
  name: nginx-exec
version: v7
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "nginx-*"
    kubernetes_groups:
    - execAndLogs

이 경우, kube-viewer 역할은 사용자를 Kubernetes viewer 그룹에 매핑하여, 사용자가 파드를 가져오고 목록을 조회할 수 있지만 명령을 실행하거나 로그를 검색할 수는 없도록 합니다. nginx-exec 역할을 사용하면, 사용자는 명령을 실행하고 로그를 검색할 수 있는 execAndLogs 그룹에 접근할 수 있지만, nginx 파드에서만 가능합니다.

이 설정에서는 Teleport 사용자의 요구 사항에 따라 kube-viewer 역할을 파드의 부분 집합에 대한 상승된 접근 권한을 부여하는 다른 역할과 결합할 수도 있습니다.

보안 고려 사항: 리소스 네임스페이스 제한#

Teleport 사용자가 예를 들어 kubectl get pods로 파드 목록 조회 요청을 보내면, Teleport Kubernetes 서비스는 다음을 수행합니다:

• 사용자의 Teleport 역할을 기반으로 임퍼소네이션 헤더를 요청에 추가하여 상위 Kubernetes API 서버에서 사용 가능한 파드를 가져옵니다. 여기에는 사용자가 요청을 보낼 때 사용하는 Kubernetes 사용자와 그룹이 포함됩니다.
• kubernetes_resources를 통해 사용자가 접근할 권한이 있는 파드를 기준으로 사용 가능한 파드 목록을 필터링합니다.
• 파드 목록을 사용자에게 반환합니다.

의도치 않게 리소스가 유출되는 것을 방지하려면, Kubernetes RBAC의 네임스페이스 제한이 Teleport에 설정한 제한과 일치하는지 확인해야 합니다.

예를 들어, 사용자가 어떤 네임스페이스의 어떤 파드에도 접근을 허용하는 Teleport 역할을 가지고 있고, 해당 사용자를 default-pod-viewer Kubernetes 그룹에 매핑한다고 가정해 보겠습니다. 이 그룹은 default 네임스페이스의 파드만 볼 수 있습니다:

kind: role
metadata:
  name: kube-access-1
version: v7
spec:
  allow:
    kubernetes_groups:
      - default-pod-viewer
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"
    # ...

사용자는 두 번째 Teleport 역할을 가지고 있으며, 이는 사용자를 system:masters Kubernetes 그룹(모든 네임스페이스의 모든 파드에 접근 가능)에 매핑하고, default 네임스페이스의 webapp 파드에만 접근 권한을 부여합니다:

metadata:
  name: kube-access-2
version: v7
spec:
  allow:
    kubernetes_groups:
      - system:masters
    kubernetes_resources:
      - kind: pod
        namespace: "default"
        name: "webapp"
    # ...

kube-access-2 역할이 사용자를 system:masters에 매핑하므로, Kubernetes 서비스가 이 사용자로부터 요청을 전달할 때 요청의 임퍼소네이션 헤더에 system:masters 그룹을 추가하여 Kubernetes 클러스터에서 모든 파드를 가져옵니다.

그러나 사용자는 모든 네임스페이스의 모든 파드에 대한 접근을 허용하는 역할(kube-access-1)도 가지고 있으므로, Kubernetes 서비스는 API 서버에 대한 첫 번째 요청을 통해 가져온 파드를 필터링하지 않습니다.

즉, Kubernetes 서비스는 Teleport가 default 네임스페이스의 webapp 파드에만 접근을 허용하기 위해 사용자를 system:masters 그룹에 매핑했다는 것을 알 방법이 없습니다.

Teleport RBAC에 네임스페이스 제한이 있는 경우, Teleport 사용자에게 매핑하는 Kubernetes RBAC 리소스에도 동일한 네임스페이스 제한이 있는지 확인해야 합니다.

예를 들어, 다음과 같은 권한을 갖도록 kube-access-1 역할을 다시 작성하여 사용자를 default 네임스페이스의 파드로 제한해야 합니다:

kind: role
metadata:
  name: kube-access-1
version: v7
spec:
  allow:
    kubernetes_groups:
      - default-pod-viewer
    kubernetes_resources:
      - kind: pod
        namespace: "default"
        name: "*"
    # ...