Teleport 권한 부여 | Teleport 공식 기술 문서 한국판 by 인포그랩

Teleport 권한 부여

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

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

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

사용자 및 역할

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

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

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

대화형 사용자

대화형 사용자는 로컬 또는 외부일 수 있습니다.
로컬 사용자 계정은 로그인 자격 증명 - 비밀번호 해시 및 MFA 장치 데이터를 Teleport의 백엔드에 저장합니다.
외부 사용자 계정은 SSO 프로토콜 - OAuth 2.0, OIDC 또는 SAML을 사용하여 제3자 신원 공급자로 인증됩니다.

SSO 공급자의 외부 사용자

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

SSO 사용자가 로그인할 때마다 Teleport는 임시 사용자 계정 레코드를 생성합니다
이 레코드는 SSO 세션과 함께 자동으로 만료되며 감사 로그 항목이 기록됩니다.

Teleport는 로컬 사용자와의 이름 충돌을 피하기 위해 이 레코드를 생성합니다.

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

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

로컬 대화형 사용자

로컬 대화형 사용자는 자격 증명이 포함된 Teleport의 백엔드에 레코드가 있습니다.

클러스터 관리자는 tctl users add 또는 API 호출을 통해 Teleport 사용자마다 계정 항목을 생성해야 합니다.

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

비대화형 사용자

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

로컬 비대화형 사용자

로컬 비대화형 사용자도 역할에 이름을 매핑하는 사용자 항목이 있지만, 데이터베이스에 저장된 자격 증명이 없습니다.
비대화형 사용자는 Teleport의 머신 ID 제품을 사용하여 인증서를 수신하고 갱신해야 합니다.
Teleport 머신 ID의 봇은 서비스와 함께 실행되며 비대화형 사용자를 대신하여 SSH 및 X.509 인증서를 회전합니다:

Machine-ID 인증서

외부 비대화형 사용자

외부 비대화형 사용자는 로컬 사용자와 동일하게 작동하지만, 인증서는 다른 클러스터 또는 인증 기관이 발급합니다.

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

역할 기반 접근 제어

모든 Teleport 사용자에게는 자원 및 Teleport API에 대한 접근 권한을 관리하는 하나 이상의 역할이 부여됩니다.

허용 및 거부 규칙

각 Teleport 역할은 두 개의 규칙 목록인 허용 규칙과 거부 규칙으로 작동합니다:

기본적으로 모든 것이 거부됩니다.
거부 규칙이 먼저 평가되며 우선권을 가집니다.
규칙은 자원과 동사라는 두 부분으로 구성됩니다.

다음은 세션 자원에 적용된 목록 동사를 설명하는 허용 규칙의 예입니다.
이는 "이 역할의 사용자가 기록된 SSH 또는 Kubernetes 세션 목록을 볼 수 있도록 허용합니다"를 의미합니다.

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

주체 (Principals)

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

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

사용자가 여러 역할을 가지고 있는 경우, 주체 목록은 하나의 집합으로 병합됩니다.

레이블 (Labels)

역할 레이블은 역할이 적용되는 리소스 규칙을 정의합니다. 예를 들어, 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 역할은 SSH 접근을 root 로 허용하며, 'test' 또는 'stage'와 일치하는 레이블을 가진 모든 Kubernetes 클러스터 또는 노드에 대해 system:masters 로 무제한 접근을 허용합니다.

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 역할은 SSH 접근을 ubuntu 로 허용하며, 'prod'와 일치하는 레이블을 가진 모든 Kubernetes 클러스터 또는 노드에 대해 view 접근을 허용합니다.

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:
    # internal.logins - 로컬 사용자 특성에서 보간됩니다 -
    # 사용자를 생성할 때 할당할 수 있는 속성입니다.
    logins: ["{{internal.logins}}"]

    # kubernetes_groups는 이 역할을 가진 사용자가 수용할 Kubernetes 그룹을 지정합니다.
    # "external" 속성 집합을 통해 SAML/OIDC 특성을 참조할 수 있습니다.
    # 이를 통해 아이덴티티 관리자에서 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 는 유효한 유닉스 로그인으로 간주되지 않으므로, 변수 external.foo 가 "-foo"와 같으면 logins: ["{{external.foo}}"]에서 생략됩니다.

Teleport 역할에서 변수 확장이 어떻게 작동하는지에 대한 전체 세부정보는 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에 인증하고 아이덴티티 공급자로부터 다음 변수를 받습니다:

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)

모든 리소스 규칙에서 where 필드를 사용할 수 있습니다. 전체 역할 참조에서 자세한 역할 사양을 확인하세요.

역할 옵션

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

kind: role
version: v5
metadata:
  name: relaxed
spec:
  # 옵션은 사용자가 여러 개의 비기본 모순 옵션을 가질 경우 연결을 지정합니다.
  # 텔레포트는 가장 허용적인 값을 선택합니다.
  options:
    # max_session_ttl은 이 역할을 가진 사용자에게 발급된 인증서의 TTL(유효 기간)을 정의합니다.
    max_session_ttl: 8h
    # lock은 이 역할의 사용자에 대한 잠금 모드를 설정합니다.
    # 유효한 값은 "strict" 또는 "best_effort"입니다.
    lock: strict

사용자가 모순 옵션을 지정하는 여러 역할을 가질 경우, 예를 들어 역할 relaxed 가 max_session_ttl 을 8h 로 설정하고 restricted 가 max_session_ttl 을 4h 로 설정하면, 가장 보안이 강화된 값이 사용됩니다. 이 경우 텔레포트는 세션을 4시간으로 제한하도록 선택합니다.

텔레포트는 다른 값에도 같은 논리를 적용합니다. 예를 들어, 두 역할이 모두 strict 및 best_effort 옵션을 지정하면, 텔레포트는 strict 옵션을 선택합니다.

필요한 순간 접근 요청

필요한 순간 접근 요청의 전체 버전은 텔레포트 엔터프라이즈(엔터프라이즈 클라우드 포함)에서만 사용할 수 있습니다.

역할은 승격된 권한을 요청할 수 있습니다 - 다른 역할 또는 개별 리소스.

역할은 누구가 권한 요청을 검토할 수 있는지를 제어하고, 얼마나 많은 승인 또는 거부가 필요한지를 정의합니다:

spec:
  allow:
    # review_requests는 이 역할을 가진 사용자가
    # 접근 요청을 승인하거나 거부할 수 있게 허용합니다.
    review_requests:
      roles: ["dbadmin"]

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

다음 단계

Teleport 원문 보기