Teleport는 인증과 권한 부여를 모두 처리합니다.

• 인증은 사용자 또는 서비스의 신원을 증명하는 것입니다.
• 권한 부여는 무언가에 대한 접근 권한이 있음을 증명하는 것입니다.

이 문서에서는 RBAC를 통한 사용자 및 서비스의 권한 부여를 설명합니다.

사용자 및 역할#

Teleport는 여러 유형의 사용자 계정을 지원합니다:

• 대화형 및 비대화형.
• 로컬 및 외부.

각 사용자는 성공적인 인증 후 하나 이상의 역할과 연결됩니다.

대화형 사용자#

대화형 사용자는 로컬 또는 외부 사용자일 수 있습니다. 로컬 사용자 계정은 로그인 자격 증명(비밀번호 해시 및 MFA 장치 데이터)을 Teleport 백엔드에 저장합니다. 외부 사용자 계정은 SSO 프로토콜(OAuth 2.0, OIDC 또는 SAML)을 사용하여 서드파티 identity provider로 인증합니다.

SSO 공급자의 외부 사용자#

조직의 SSO 공급자를 사용하여 Teleport에 인증하는 Alice의 예를 살펴보겠습니다:

다른 클러스터의 외부 사용자#

사용자는 다른 클러스터 또는 인증 기관이 이 클러스터가 신뢰하는 인증서를 발급하는 경우 Teleport 클러스터에 외부 사용자가 될 수 있습니다. 이 경우, Teleport는 신뢰할 수 있는 클러스터 매핑 로직을 활성화합니다.

로컬 대화형 사용자#

로컬 대화형 사용자는 Teleport 백엔드에 자격 증명이 있는 레코드를 가집니다.

클러스터 관리자는 tctl users add 또는 API 호출로 모든 Teleport 사용자에 대한 계정 항목을 만들어야 합니다.

모든 로컬 Teleport 사용자는 하나 이상의 역할 목록과 연결되어야 합니다. 이 목록을 "역할 매핑"이라고 합니다.

비대화형 사용자#

Teleport는 Jenkins 또는 조직에서 실행 중인 마이크로서비스와 같은 자동화 서비스를 위한 비대화형 사용자를 지원합니다.

로컬 비대화형 사용자#

로컬 비대화형 사용자도 이름을 역할에 매핑하는 사용자 항목을 가지지만, 데이터베이스에 자격 증명이 저장되어 있지 않습니다. 비대화형 사용자는 Teleport 머신 및 워크로드 아이덴티티 제품을 사용하여 인증서를 받고 갱신해야 합니다. Teleport 머신 및 워크로드 아이덴티티의 Bot은 서비스 옆에서 실행되며 비대화형 사용자를 대신하여 SSH 및 X.509 인증서를 교체합니다:

외부 비대화형 사용자#

외부 비대화형 사용자는 로컬 사용자처럼 동작하지만, 해당 인증서는 다른 클러스터 또는 인증 기관에 의해 발급된다는 점이 다릅니다.

Teleport 백엔드에 로컬 사용자 레코드가 없습니다. Teleport는 이 사용 사례를 지원하기 위해 신뢰할 수 있는 클러스터 매핑 로직을 활성화합니다.

역할 기반 접근 제어#

모든 Teleport 사용자는 리소스 및 Teleport API에 대한 접근을 관리하는 하나 이상의 역할이 할당됩니다.

허용 및 거부 규칙#

각 Teleport 역할에는 allow 규칙 목록 및/또는 deny 규칙 목록이 있을 수 있습니다:

• 기본적으로 모든 것이 거부됩니다.
• 거부 규칙이 먼저 평가되고 우선순위를 가집니다.
• 규칙은 리소스와 동사 두 부분으로 구성됩니다.

다음은 session 리소스에서 list 작업을 허용하는 allow 규칙의 예입니다. 이는 "이 역할의 사용자가 녹화된 SSH 또는 Kubernetes 세션 목록을 볼 수 있도록 허용"을 의미합니다.

allow:
  - resources: [session]
    verbs: [list]

주체#

역할은 역할에 할당된 사용자가 가정할 수 있는 주체(예: Linux OS 사용자 또는 Kubernetes 그룹)를 정의합니다:

spec:
  allow:
    # logins 배열은 사용자가 사용할 수 있는 OS/UNIX 로그인을 정의합니다.
    logins: [ubuntu]
    # kubernetes_groups는 사용자가 가정할 수 있는 Kubernetes 그룹을 정의합니다.
    kubernetes_groups: [viewer]

사용자가 여러 역할을 가진 경우, 주체 목록은 하나의 세트로 병합됩니다.

레이블#

역할 레이블은 역할의 규칙이 적용되는 리소스를 정의합니다. 예를 들어, SSH 노드 및 Kubernetes 클러스터에 대한 접근을 지정하는 역할을 살펴보겠습니다:

spec:
  allow:
    # 사용자가 연결할 수 있는 노드 레이블 목록:
    node_labels:
      # 정규 표현식도 지원됩니다. 예를 들어, 위 목록 예시와 동등한 것은
      # 다음과 같이 표현할 수 있습니다:
      'environment': '^test|staging$'

    kubernetes_labels:
      # 사용자는 us-west의 모든 리전에 접근할 수 있습니다. 예: us-west-1, us-west-2
      'region': 'us-west-*'
      'cluster_name': '^us.*\.example\.com$'

레이블, 허용 규칙 및 주체가 적용되는 방식은 다음과 같습니다:

• allow 규칙이 일치하려면 규칙의 모든 레이블이 일치해야 합니다. 예를 들어, 위 Kubernetes 규칙에서 region과 cluster_name이 모두 일치해야 합니다.
• deny 규칙이 일치하려면 규칙의 레이블 중 하나라도 일치할 수 있습니다.

주체와 레이블

Alice에게 dev 및 prod 두 가지 역할이 할당되어 있다고 가정해봅시다:

dev 역할은 'test' 또는 'stage'와 일치하는 레이블이 있는 모든 Kubernetes 클러스터 또는 노드에 대해 root로의 SSH 접근과 system:masters로의 Kubernetes에 대한 무제한 접근을 허용합니다.

metadata:
  name: dev
spec:
  allow:
    logins: [root]
    kubernetes_groups: ['system:masters']
    # 사용자가 연결할 수 있는 노드 레이블 목록:
    node_labels:
       'environment': ['test', 'stage']
    kubernetes_labels:
       'environment': ['test', 'stage']
    # 위에 지정된 레이블이 있는 클러스터의 모든 Kubernetes 리소스에 대한 접근 허용
    kubernetes_resources:
      - kind: '*'
        namespace: '*'
        name: '*'
        verbs: ['*']

Prod 역할은 'prod'와 일치하는 레이블이 있는 모든 Kubernetes 클러스터 또는 노드에 대해 ubuntu로의 SSH 접근과 view Kubernetes 접근을 허용합니다.

metadata:
  name: prod
spec:
  allow:
    logins: [ubuntu]
    kubernetes_groups: ['view']
    node_labels:
       'environment': ['prod']
    kubernetes_labels:
       'environment': ['prod']
    kubernetes_resources:
      - kind: '*'
        namespace: '*'
        name: '*'
        verbs: ['*']

Teleport가 Alice의 접근을 평가하는 방법은 다음과 같습니다:

• Alice는 test 또는 stage로 레이블이 지정된 서버에 root로 SSH 접근할 수 있습니다.
• Alice는 prod 레이블이 지정된 서버에 root로 SSH 접근할 수 없습니다. prod 역할은 prod 레이블 서버에 ubuntu로만 접근을 허용하기 때문입니다.

Kubernetes에도 동일하게 적용됩니다:

• Alice는 test 또는 stage로 레이블이 지정된 경우 system:masters로 Kubernetes 클러스터에 접근할 수 있습니다.
• Alice는 prod로 레이블이 지정된 경우 view 역할로만 Kubernetes 클러스터에 접근할 수 있습니다.

역할 템플릿#

역할은 템플릿 변수를 지원합니다. 다음은 변수가 보간되는 방법을 설명하는 역할 스니펫입니다.

spec:
  # allow 섹션은 이 역할의 사용자에게 허용되는 리소스/동사 조합의 목록을 선언합니다.
  # 기본적으로 아무것도 허용되지 않습니다.
  allow:
    # internal.logins - 사용자 생성 시 할당할 수 있는 속성인 로컬 사용자의 특성에서 보간됩니다.
    logins: ['{{internal.logins}}']

    # kubernetes_groups는 이 역할의 사용자가 가정할 Kubernetes 그룹을 지정합니다.
    # "external" 속성 백을 통해 SAML/OIDC 특성을 참조할 수 있습니다.
    # 이를 통해 identity manager에서 Kubernetes 그룹 멤버십을 지정할 수 있습니다:
    kubernetes_groups: ['{{external.groups}}']

변수 보간 규칙

• external.groups가 ["dev", "prod"]를 포함하는 목록인 경우, ["{{external.groups}}"] 표현식은 ["dev", "prod"] 목록으로 보간됩니다.
• external.groups가 "dev"와 같은 변수인 경우, ["{{external.groups}}"] 표현식은 ["dev"]로 보간됩니다.
• external.groups가 없는 경우, "{{external.groups}}" 표현식은 빈 문자열 ""로 평가됩니다. 템플릿에서 술어 언어 함수 호출을 사용할 수 있습니다. 예: {{email.local(external.foo)}}.
• 문자열 접두사와 값을 결합할 수 있습니다. 예: "IAM#{{regexp.replace(external.foo, "^bar-(.*)$", "$1")}};".
• 잘못된 표현식은 무시됩니다. 예: external.foo}}는 무효 함수 호출과 마찬가지로 건너뜁니다.
• 잘못된 값은 생략됩니다. 예를 들어 -foo는 유효한 Unix 로그인이 아니므로, 변수 external.foo가 "-foo"와 같으면 logins: ["{{external.foo}}"]에서 생략됩니다.

Teleport 역할에서 변수 확장이 작동하는 방법에 대한 전체 세부 정보는 접근 제어 레퍼런스를 참조하세요.

역할 템플릿 평가 방법

프록시 서비스 인스턴스, Auth 서비스 인스턴스 또는 Agent 등 모든 Teleport 구성 요소는 모든 역할의 최신 사본을 가지고 있습니다. Teleport 구성 요소는 모든 리소스에 대한 접근 시점에 역할 템플릿을 평가합니다.

다음 역할 템플릿이 있는 경우를 살펴보겠습니다:

metadata:
  name: devs
spec:
  allow:
    kubernetes_groups: ["{{external.k8s_groups}}"]
    kubernetes_labels:
       "env": ["{{external.env}}"]
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"

사용자 Alice는 Teleport에 인증하고 identity provider로부터 다음 변수를 받습니다:

k8s_groups: ["view", "edit"]
env: ["stage"]

이 변수들은 X.509 인증서의 확장으로 인코딩됩니다.

프록시 서비스가 Kubernetes 클러스터에 연결하려는 시도를 권한 부여할 때, 역할 템플릿과 변수를 보간하여 다음을 얻습니다:

metadata:
  name: devs
spec:
  allow:
    kubernetes_groups: ["view", "edit"]
    kubernetes_labels:
       "env": ["stage"]
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"

마지막으로, 프록시는 결과 역할을 Alice가 접근하려는 Kubernetes 클러스터에 적용하고 클러스터와 비교하여 확인합니다. 클러스터에 "env": "stage" 레이블이 있으면 시도가 성공하고, 그렇지 않으면 실패합니다.

역할 조건#

아래 예는 역할 조건을 사용하여 세션을 만든 사용자만 세션 접근을 제한하는 방법을 보여줍니다:

kind: role
metadata:
  name: only-own-sessions
spec:
  allow:
    rules:
    # 사용자는 자신이 참가한 세션의 세션 녹화만 볼 수 있습니다.
    - resources: [session]
      verbs: [list, read]
      where: contains(session.participants, user.metadata.name)

역할 옵션#

allow 및 deny 규칙과 함께, 역할은 다양한 옵션을 제어합니다. 예를 들어:

kind: role
version: v5
metadata:
  name: relaxed
spec:
  # options는 연결을 지정합니다. 사용자가 여러 개의 기본이 아닌
  # 충돌하는 옵션을 가진 경우, teleport는 가장 제한적인 값을 선택합니다.
  options:
    # max_session_ttl은 이 역할의 사용자에게 발급된 인증서의 TTL(time to live)을 정의합니다.
    max_session_ttl: 8h
    # lock은 이 역할의 사용자에 대한 잠금 모드를 설정합니다.
    # 유효한 값은 "strict" 또는 "best_effort"입니다.
    lock: strict

사용자가 충돌하는 옵션을 지정하는 여러 역할을 가진 경우, 가장 안전한 값이 사용됩니다. 예를 들어, relaxed 역할이 max_session_ttl을 8h로 설정하고 restricted 역할이 max_session_ttl을 4h로 설정하면, Teleport는 4h 값을 사용합니다.

Teleport는 다른 값에도 동일한 로직을 적용합니다. 예를 들어 두 역할이 strict와 best_effort 옵션을 모두 지정하면, Teleport는 strict 옵션을 선택합니다.

즉시 접근 요청#

역할은 상승된 권한(다른 역할 또는 개별 리소스)을 요청할 수 있도록 허용합니다.

역할은 권한 요청을 검토할 수 있는 사람과 필요한 승인 또는 거부의 수를 정의합니다:

spec:
  allow:
    # review_requests는 이 역할을 보유한 사용자가
    # 접근 요청을 승인하거나 거부할 수 있도록 합니다.
    review_requests:
      roles: ['dbadmin']

    # request는 사용자가 아래 표현식과 일치하는 역할을 요청할 수 있도록 합니다.
    request:
      # `roles` 목록은 리터럴과 와일드카드 매처의 혼합이 될 수 있습니다.
      roles: ['common', 'dev-*']
      # thresholds는 최소 승인자 및 거부자 수를 지정합니다.
      # 기본값은 둘 다 1입니다.
      thresholds:
        # 최소 두 명의 자격 있는 승인자와 최소 한 명의 거부자를 요구합니다.
        - approve: 2
          deny: 1

다음 단계#

• 접근 제어 레퍼런스.
• Teleport 술어 언어.
• 접근 요청 가이드
• 아키텍처 개요
• Teleport Auth
• Teleport Agent
• Teleport 프록시