Infograb logo
텔레포트 접근 제어 참조

이 가이드에서는 텔레포트 역할을 사용하여 텔레포트 클러스터에서 역할 기반 접근 제어(RBAC)를 관리하는 방법을 보여줍니다.

텔레포트 역할은 allow 규칙과 deny 규칙의 두 가지 규칙 목록으로 접근을 관리합니다. 접근 규칙을 선언할 때 다음 사항을 염두에 두세요:

  • 기본적으로 아무것도 허용되지 않습니다.
  • 거부 규칙이 먼저 평가되며 우선권을 가집니다.

다음 방법 중 하나를 사용하여 텔레포트 역할 및 기타 동적 리소스를 관리할 수 있습니다:

  • 텔레포트 웹 UI
  • tctl 클라이언트 도구
  • 텔레포트 테라폼 프로바이더
  • 텔레포트 쿠버네티스 운영자
  • 커스텀 API 클라이언트

동적 리소스 관리에 대해 자세히 읽으려면 동적 리소스 가이드를 참조하세요.

클러스터의 모든 역할을 로컬 워크스테이션에서 확인하려면 다음 명령어를 실행하세요:

로컬 머신에서 tctl을 사용하려면 tsh로 클러스터에 로그인합니다.

tsh login --user=myuser --proxy=mytenant.teleport.sh
tctl get roles
경고

프로덕션 인스턴스, 환경 및/또는 설정을 영구적으로 수정하기 전에 백업하는 것이 모범 사례로 권장됩니다. 이렇게 하면 필요할 경우 기존 상태로 롤백할 수 있습니다.

예시 역할 사양

여기 전체 역할 사양이 있습니다:

kind: role
version: v7
metadata:
  name: example
  description: This is an example role.
spec:
  # 옵션은 연결을 지정하며, 사용자가 여러 개의 비기본
  # 충돌 옵션을 가지고 있을 경우, teleport는 가장 제한적인 값을 선택합니다.
  options:
    # max_session_ttl은 이 역할을 가진 사용자에게 발급된 인증서의 TTL(유효 기간)을 정의합니다.
    max_session_ttl: 8h
    # forward_agent는 SSH 에이전트 포워딩이 허용되는지를 제어합니다.
    forward_agent: true
    # port_forwarding은 SSH에 대한 TCP 포트 포워딩이 허용되는지를 제어합니다.
    port_forwarding: true
    # ssh_file_copy는 파일 복사(SCP/SFTP)가 허용되는지를 제어합니다.
    # 기본값은 true입니다.
    ssh_file_copy: false
    # client_idle_timeout은 클러스터 노드에 대한 SSH 세션이
    # 클라이언트의 활동이 없을 경우(유휴 클라이언트) 강제로 종료되는지를 결정합니다.
    # 전역 클러스터 설정을 재정의합니다. 예시: '30m', '1h' 또는 '1h30m'
    client_idle_timeout: never
    # 클라이언트의 인증서가 활성 세션 중간에 만료될 때
    # 클라이언트가 강제로 연결 해제되도록 할지를 결정합니다.
    # 전역 클러스터 설정을 재정의합니다.
    disconnect_expired_cert: no
    # max_sessions는 단일 연결을 통해 설정할 수 있는 세션 채널의 총 수입니다.
    # 10으로 설정하면 OpenSSH의 기본 동작과 일치합니다.
    # (기업 전용)
    max_sessions: 10
    # 향상된 기록을 통해 BPF 기반 세션 레코더에 의해 기록되는 이벤트를 정의합니다.
    enhanced_recording:
    - command
    - disk
    - network
    # permit_x11_forwarding은 사용자가 openssh 클라이언트와 서버를 통해
    # X11 포워딩을 사용할 수 있도록 허용합니다.
    permit_x11_forwarding: true
    # device_trust_mode는 이 역할에 할당된 사용자의 인증된 장치 접근을 강제합니다.
    device_trust_mode: optional|required|off
    # require_session_mfa는 이 역할을 가진 모든 할당 사용자에 대해 세션별 MFA를 요구합니다.
    require_session_mfa: true
    # mfa_verification_interval은 선택적으로 연속 MFA 검증 사이에 경과할 수 있는 최대 기간을 정의합니다.
    # 이 변수는 사용자가 주기적으로 자신의 신원을 확인하도록 유도하여
    # 장기적인 재인증 없이는 만료되는 세션을 방지하여 보안을 강화하는 데 사용됩니다.
    mfa_verification_interval: 1h
    # lock은 이 역할의 사용자에 대한 잠금 모드를 설정합니다.
    # 유효한 값은 'strict' 또는 'best_effort'입니다.
    lock: strict
    # 기업 전용 request_access 필드는 'optional', 'always' 또는 'reason'입니다. 항상 또는 reason으로 설정할 경우,
    # tsh 또는 웹 UI 클라이언트에 각각 Access Request를 항상 생성하도록 지시합니다. 'reason'로 설정할 경우,
    # 사용자는 Access Request를 생성하는 이유를 표시해야 합니다.
    request_access: reason
    # 'request_prompt' 필드는 사용자에게 요청 이유 필드에 무엇을 제공해야 하는지를 알려주는 데 사용할 수 있습니다.
    request_prompt: 티켓 ID를 제공해 주십시오.
    # 기업 전용 max_connections 필드는 클러스터 내 동시 세션의 한계를 설정합니다.
    # 이 설정은 Teleport 성능을 저하시킵니다. 왜냐하면 클러스터 전반에 걸쳐 연결을 추적해야 하기 때문입니다.
    max_connections: 2
    # 사용자당 동시 Kubernetes 세션 수를 제한합니다.
    max_kubernetes_connections: 1
    # Teleport가 세션 기록 실패(예: 디스크 오류) 시 처리하는 방법을 정의합니다.
    # 값은 'best_effort' 또는 'strict'로 설정할 수 있습니다. 
    # 'strict'로 설정하면 세션이 즉시 종료됩니다. 
    # 'best_effort'로 설정하면 세션이 종료되지 않으며, 기록이 비활성화됩니다. 
    # 이 구성은 서비스마다 설정됩니다(현재는 'ssh'만 지원됨).
    record_session:
      # 사용자의 데스크톱 세션을 기록할지를 지정합니다.
      # 데스크톱 세션 기록은 사용자의 역할 중 하나라도 기록을 활성화하면 가능됩니다. 
      # 지정되지 않은 경우 기본적으로 true입니다.
      # auth_service.session_recording이 teleport.yaml(Auth Service)에서 'off'로 설정된 경우 
      # 또는 클러스터의 session_recording_config 리소스가 'mode: off'로 설정된 경우
      # 데스크톱 세션은 결코 기록되지 않습니다.
      desktop: true
      # 선택 사항: 프로토콜별 모드가 설정되지 않은 경우 사용할 기본 세션 기록 모드입니다.
      default: best_effort|strict
      # 선택 사항: SSH 세션의 세션 기록 모드입니다(Телепорт 서버 접근).
      # 설정되지 않은 경우, 기본값에 설정된 값이 사용됩니다.
      ssh: best_effort|strict
    # 원격 데스크톱과의 클립보드 공유가 허용되는지를 지정합니다.
    # 기본값은 지정되지 않았을 경우 true입니다. 
    # 사용자의 역할 중 하나라도 클립보드를 비활성화하면 비활성화됩니다.
    desktop_clipboard: true
    # 기업 전용: 활성화되면 로그인에 사용된 소스 IP가 사용자
    # 인증서에 포함되어, 손상된 인증서가 다른 네트워크에서 사용되지 못하도록 합니다. 기본값은 false입니다.
    pin_source_ip: true
    # 사용자 SSH 키에 포함될 이름과 관련된 값을 명시합니다.
    # 키 타입은 'ssh'만 가능하며 모드는 'extension'만 가능합니다.
    # 이름과 값 필드는 임의 문자열이 될 수 있으며, 
    # 값 필드는 변수 보간을 지원합니다.
    cert_extensions:
     - type: ssh
       mode: extension
       name: login@github.com
       value: '{{ external.github_login }}'
    # 이 역할이 SSH 사용자 자동 프로비저닝을 지원하는지를 제어합니다.
    # 옵션: keep (세션 종료 시 사용자 유지), insecure-drop (세션 종료 시 사용자 제거),
    #          off (호스트 사용자 생성을 비활성화)
    create_host_user_mode: keep
    # 이 역할이 자동 데이터베이스 사용자 프로비저닝을 요구하는지를 제어합니다.
    # 옵션: off (데이터베이스 사용자 자동 프로비저닝 비활성화),
    # keep (세션 종료 시 사용자를 비활성화하고 역할을 제거하여 잠급니다),
    # best_effort_drop (세션 종료 시 사용자를 제거하려고 시도하고, 실패하면 비활성화로 되돌리기).
    create_db_user_mode: keep
    # ID 공급자 접근을 위한 역할 특정 옵션을 명시합니다.
    idp:
      # SAML ID 공급자 접근을 위한 역할 특정 옵션을 명시합니다.
      saml:
        # 이 역할이 SAML ID 공급자에 접근할 수 있는지를 지정합니다.
        # 기본값은 true입니다.
        enabled: true

  # allow 섹션은 이 역할의 사용자에게 허용되는 리소스/동사 조합의 목록을 선언합니다.
  # 기본적으로는 무엇도 허용되지 않습니다.
  allow:
    # logins 배열은 사용자가 사용할 수 있는 OS/UNIX 로그인을 정의합니다.
    # 이 필드에서는 문자열 및 템플릿 변수가 모두 지원됩니다.
    logins: [root, '{{internal.logins}}']

    # Windows 로그인, 사용자가 데스크톱 세션에 사용할 수 있는 것.
    windows_desktop_logins: [Administrator, '{{internal.logins}}']

    # node_labels: 이 역할을 가진 사용자는 아래와 일치하는 레이블을 가진 SSH 노드에 연결할 수 있습니다.
    node_labels:
      # 리터럴 문자열:
      'env': 'test'
      # 와일드카드('*')는 어떤 노드에도 해당됩니다.
      '*': '*'
      # 대체 옵션 목록:
      'region': ['us-west-1', 'eu-central-1']
      # 정규 표현식은 ^로 시작하고 $로 끝납니다.
      # Teleport는 Go의 정규 표현식 구문을 사용합니다:
      # https://github.com/google/re2/wiki/Syntax
      # 위의 목록 예시는 다음과 같이 표현할 수 있습니다:
      # 'region': '^us-west-1|eu-central-1$'
      'reg': '^us-west-1|eu-central-1$'

    # 생성된 사용자가 추가될 호스트 그룹의 목록입니다. 
    # 이미 존재하지 않는 그룹은 생성됩니다. create_host_user_mode가 'off'가 아닐 때만 적용됩니다.
    host_groups: [ubuntu, nginx, other]

    # `/etc/sudoers.d`에서 생성된 임시 sudoers 파일에 포함할 항목 목록입니다.
    # 레코드는 세션 종료 시 제거됩니다.
    host_sudoers: [
      # 이 줄은 로그인한 사용자가 비밀번호 없이 root로서 `systemctl restart nginx.service`를 실행할 수 있도록 허용합니다.
      "ALL = (root) NOPASSWD: /usr/bin/systemctl restart nginx.service"
    ]

    # kubernetes_groups는 이 역할을 가진 사용자가 맡게 되는 Kubernetes 그룹을 지정합니다.
    # 'external' 속성 집합을 통해 SAML/OIDC 특성을 참조할 수 있습니다.
    # 이를 통해 ID 관리자에서 Kubernetes 그룹 멤버십을 지정할 수 있습니다:
    kubernetes_groups: ['system:masters', '{{external.trait_name}}']

    # kubernetes_users는 이 역할이 맡을 수 있는 Kubernetes 사용자입니다.
    kubernetes_users: ['IAM#{{external.foo}};']

    # kubernetes_labels: 이 역할을 가진 사용자는 아래와 일치하는 레이블을 가진 k8s 클러스터에 연결할 수 있습니다.
    kubernetes_labels:
      # 사용자는 프로덕션 환경에만 접근할 수 있습니다.
      'env': 'prod'
      # 사용자는 us-west의 모든 지역에 접근할 수 있습니다(예: us-west-1, us-west-2)
      'region': 'us-west-*'
      # 정규 표현식은 ^로 시작하고 $로 끝납니다.
      # Teleport는 Go의 정규 표현식 구문을 사용합니다:
      # https://github.com/google/re2/wiki/Syntax
      # 위의 목록 예시는 다음과 같이 표현할 수 있습니다:
      # 'region': '^us-west-1|eu-central-1$'
      'cluster_name': '^us.*\.example\.com$'

    # kubernetes_resources는 이 역할을 가진 사용자가 접근할 수 있는 Kubernetes 리소스를 나타냅니다.
    kubernetes_resources:
        # 리소스 종류. Teleport는 현재 지원하는 종류:
        # - * (모든 리소스)
        # - pod
        # - secret
        # - configmap
        # - namespace
        # - service
        # - serviceaccount
        # - kube_node
        # - persistentvolume
        # - persistentvolumeclaim
        # - deployment
        # - replicaset
        # - statefulset
        # - daemonset
        # - clusterrole
        # - kube_role
        # - clusterrolebinding
        # - rolebinding
        # - cronjob
        # - job
        # - certificatesigningrequest
        # - ingress
      - kind: '*'
        # 리소스에 대한 접근을 허용할 Kubernetes 네임스페이스의 이름입니다.
        # 와일드카드 *는 모든 문자 시퀀스와 일치합니다.
        # 값이 ^로 시작하고 $로 끝날 경우, Kubernetes
        # 서비스는 이를 정규 표현식으로 처리합니다.
        namespace: '*'
        # 접근을 허용할 리소스의 이름입니다.
        # 와일드카드 *는 모든 문자 시퀀스와 일치합니다.
        # 값이 ^로 시작하고 $로 끝날 경우, Kubernetes
        # 서비스는 이를 정규 표현식으로 처리합니다.
        name: '^nginx-[a-z0-9-]+$'
        # 사용자가 리소스에서 수행할 수 있는 동사입니다.
        # Teleport는 현재 지원하는 동사:
        # - * (모든 동사)
        # - get
        # - list
        # - watch
        # - create
        # - update
        # - patch
        # - delete
        # - deletecollection
        # - exec - 사용자가 pod 내에서 명령을 실행할 수 있도록 허용
        # - portforward - 사용자가 pod에서 포트를 포워딩할 수 있도록 허용
        verbs: ['*']

    # Functions는 변수를 변환합니다.
    db_users: ['{{email.local(external.email)}}']
    db_names: ['{{external.db_names}}']
    db_labels:
      'env': '{{regexp.replace(external.env, "^(staging)$", "$1")}}'

    # 부여할 데이터베이스 역할 목록입니다. 'db_permissions'와는 상호 배타적입니다.
    db_roles: ['{{external.db_roles}}']

    # 모든 테이블에 대해 가능한 모든 Postgres 권한을 부여합니다.
    # 부여할 데이터베이스 권한 목록입니다. 'db_roles'와는 상호 배타적입니다.
    db_permissions:
    - match:
        object_kind: table
      permissions:
	    - SELECT
	    - INSERT
	    - UPDATE
	    - DELETE
	    - TRUNCATE
	    - REFERENCES
	    - TRIGGER

    # app_labels: 이 역할을 가진 사용자는 아래와 일치하는 레이블을 가진 애플리케이션에 연결할 수 있습니다.
    app_labels:
      # 사용자는 프로덕션 환경에만 접근할 수 있습니다.
      'env': 'prod'
      # 사용자는 us-west의 모든 지역에 접근할 수 있습니다(예: us-west-1, us-west-2)
      'region': 'us-west-*'
      # 정규 표현식은 ^로 시작하고 $로 끝납니다.
      # Teleport는 Go의 정규 표현식 구문을 사용합니다:
      # https://github.com/google/re2/wiki/Syntax
      # 위의 목록 예시는 다음과 같이 표현할 수 있습니다:
      # 'region': '^us-west-1|eu-central-1$'
      'cluster_name': '^us.*\.example\.com$'

    # group_labels: 이 역할을 가진 사용자는 기본 사용자 그룹에 대한 권한이 부여됩니다.
    # Okta 서비스와 같은 서비스는 이러한 권한을 사용하여 외부 서비스에 접근할 수 있습니다.
    group_labels:
      # 사용자는 프로덕션 관련 그룹에 대한 그룹 멤버십이 부여됩니다.
      'env': 'prod'

    # cluster_labels: 이 역할을 가진 사용자는 아래와 일치하는 레이블을 가진 원격
    # 클러스터에 연결할 수 있습니다.
    cluster_labels:
      'env': 'prod'

    # node_labels_expression은 node_labels와 동일한 목적을 가지며,
    # 맞춤형 논리를 구성하도록 지원하는 조건 표현식을 지원합니다.
    # 이 역할을 가진 사용자는 스테이징 환경에 있거나 사용자의 팀 중 하나에 속하는 노드에 접근할 수 있습니다.
    node_labels_expression: |
      labels["env"] == "staging" ||
      contains(user.spec.traits["teams"] , labels["team"])

    # 아래 <kind>_labels_expression 필드는 매칭 <kind>_labels 필드와 동일한 목적을 가지며,
    # 레이블 매칭기 대신 조건 표현식을 지원합니다.
    app_labels_expression: 'labels["env"] == "staging"'
    cluster_labels_expression: 'labels["env"] == "staging"'
    kubernetes_labels_expression: 'labels["env"] == "staging"'
    db_labels_expression: 'labels["env"] == "staging"'
    db_service_labels_expression: 'labels["env"] == "staging"'
    windows_desktop_labels_expression: 'labels["env"] == "staging"'
    group_labels_expression: 'labels["env"] == "staging"'

    # aws_role_arns는 이 역할을 가진 사용자가 AWS 콘솔에 
    # UI를 사용하거나 CLI를 사용하여 AWS API에 접근할 때 AWS 역할을 맡을 수 있도록 허용합니다.
    aws_role_arns:
      - 'arn:aws:iam::1234567890:role/ec2-read-only'
      - 'arn:aws:iam::1234567890:role/ec2-full-access'
      - 'arn:aws:iam::0987654321:role/example-role'

    # impersonate는 이 역할을 가진 사용자가 아래 표현과 일치하는
    # 다른 사용자와 역할을 대신하여 인증서를 발급할 수 있도록 허용합니다.
    impersonate:
      users: ['*']
      roles: ['jenkins']
      # where는 선택적인 where 조건입니다.
      # 일치하는 사용자와 역할의 범위를 더욱 제한합니다.
      where: >
        contains(user.spec.traits["group"], impersonate_role.metadata.labels["group"]) &&
        contains(user.spec.traits["group"], impersonate_user.metadata.labels["group"])

    # review_requests는 이 역할을 보유한 사용자가
    # Access Requests를 승인 또는 거부할 수 있도록 허용합니다(기업 전용).
    review_requests:
      # 리뷰어는 여기 나열된 모든 역할에 대해 접근 요청을 보고 승인하거나 거부할 수 있습니다.
      roles: ['dbadmin']
      # 리뷰어는 리소스 접근 요청을 검토할 때
      # 여기 나열된 역할이 액세스할 수 있는 리소스에 대한 세부 정보를 미리 볼 수 있습니다.
      preview_as_roles: ['dbadmin']

    # request는 사용자가 아래 표현과 일치하는 역할을 요청할 수 있도록 허용합니다.
    request:
      # 'roles' 목록은 리터럴과 와일드카드 일치기의 조합이 될 수 있습니다.
      roles: ['common', 'dev-*']

      # 'search_as_roles'는 사용자가 접근할 수 있는 리소스를 검색하고 요청할 수 있게 허용합니다.
      # (기업 전용)
      search_as_roles: ['access']

      # thresholds는 최소한의 승인자와 거부자를 지정하며,
      # 기본값은 각각 1입니다(기업 전용).
      thresholds:
        # 최소 두 명의 자격을 갖춘 승인자와 최소 한 명의 거부자가 필요합니다.
        - approve: 2
          deny: 1

      # max_duration은 사용자가 역할에 요청할 수 있는 최대 기간을 지정합니다.
      # 기간은 초(s), 분(m), 시간(h) 또는 일(d)로 지정할 수 있으며, 예: 4d, 10h, 30m, 60s.
      # 최대 기간은 14일입니다.
      max_duration: 7d

      # 'claims_to_roles' 매핑은 OIDC 커넥터와 동일하게 작동하며,
      # 매핑되는 역할이 또한 매처일 수 있다는 추가 이점이 있습니다.
      #
      # 이 예시는 Teleport의 정규 표현식 지원을 활용하여,
      # 클레임에서 동적 매핑을 가능하게 합니다. 아래 매핑은 사용자가 
      # 'projects: product-(.*)'에 해당하는 클레임을 가질 경우,
      # '$1-admin'과 매칭되는 역할을 요청할 수 있게 합니다.
      # 예: 'projects: product-foo' 클레임은 사용자가 
      # 'foo-admin' 역할을 요청할 수 있게 합니다.
      claims_to_roles:
        - claim: 'projects'
          # 접두사가 'product-'인 모든 그룹 이름과 일치합니다.
          value: '^product-(.*)$'
          # 값 캡처에서 역할 이름을 생성합니다.
          roles: ['$1-admin']

      # Teleport는 보류 중인 Access Requests에 주석을 첨부할 수 있습니다. 
      # 이러한 주석은 리터럴이거나 변수 보간 표현일 수 있으며,
      # 효과적으로 선택된 클레임을 외부 ID 공급자로부터 
      # 플러그인 시스템으로 전파할 수 있는 수단을 만듭니다.
      annotations:
        foo: ['bar']
        groups: ['{{external.groups}}']

    # Moderated Sessions 정책은 세션 시작을 위한 요구 사항을 규정합니다.
    require_session_join:
      # 정책의 이름을 정의합니다. 이름은 로그에서 식별자 역할만 하며
      # 조직화/분류를 위해 사용됩니다.
      - name: 감사자 감독
        # 요구 사용자 수를 정의하기 위해 사용되는 RBAC 조건을 지정합니다.
        filter: 'contains(user.spec.roles, 'auditor')'
        # 이 정책이 적용되는 다양한 세션 종류.
        kinds: ['k8s', 'ssh']
        # 정책을 충족하는 사용자가 가져야 할 세션 참가자 모드 목록입니다.
        modes: ['moderator']
        # 정책을 충족하기 위해 필터 표현식과 일치해야 하는 최소 사용자 수.
        count: 1
        # 감사자가 세션을 떠날 경우, 정책이 더 이상 충족되지 않게 됩니다. 
        # 이 경우의 동작은 'terminate' 또는 'pause'일 수 있습니다.
        # 비어 있거나 알 수 없는 값은 기본적으로 'terminate'로 설정됩니다.
        on_leave: 'terminate'

    # Moderated Sessions 정책은 세션에 참여할 수 있는 권한을 규정합니다.
    join_sessions:
      # 정책의 이름을 정의합니다. 이름은 로그에서 식별자 역할만 하며
      # 조직화/분류를 위해 사용됩니다.
      - name: 감사자 감독
        # 여기에서 나열된 역할로 사용자들은 다른 사용자에 의해 생성된 세션에 참여할 수 있습니다.
        roles : ['prod-access']
        # 이 정책이 적용되는 다양한 세션 종류.
        kinds: ['k8s', 'ssh']
        # 사용자가 해당 세션에 합류할 수 있는 세션 참가자 모드 목록입니다.
        modes: ['moderator', 'observer']

    # spiffe는 역할 보유자가 요청할 수 있는 SPIFFE ID 목록입니다.
    # 요청이 spiffe 목록 내의 블록 중 하나와 일치하는 한, 인증서가 발급됩니다.
    spiffe:
        # 요청할 수 있는 SPIFFE ID의 경로입니다. 이 필드는
        # 각 블록에 대해 필수입니다. '/'로 시작하고
        # 후행 '/'가 없어야 합니다.
      - path: "/svc/foo"
        # 사용자 요청 시 SVID에 포함될 IP SAN입니다.
        # 이 필드는 선택 사항이며 생략할 경우,
        # 사용자가 IP SAN이 포함된 SVID를 요청할 수 없습니다.
        ip_sans: ["10.0.0.100/32"]
        # 사용자 요청 시 SVID에 포함될 DNS SAN입니다.
        # 이 필드는 선택 사항이며 생략할 경우,
        # 사용자가 DNS SAN이 포함된 SVID를 요청할 수 없습니다.
        #
        # '*' 와일드카드 문자는 하나 이상의 어떤 문자도 지시하는 데 지원됩니다.
        # 예를 들어, '*.example.com'은 
        # 'foo.example.com'과 일치합니다.
        dns_sans: ["foo.svc.example.com"]

    # rules는 이 역할을 보유한 사용자가 아래 표현과 일치하는 다른 리소스를 수정할 수 있습니다.
    # 지원되는 리소스:
    # role               - 역할 리소스
    # user               - 사용자 리소스
    #
    # auth_connector     - 모든 인증 커넥터 리소스
    # oidc               - OIDC 커넥터 리소스
    # saml               - 커넥터 리소스
    # github             - GitHub 커넥터 리소스
    #
    # trusted_cluster    - 신뢰하는 클러스터 리소스
    # remote_cluster     - 원격 클러스터 리소스
    #
    # access_request     - 접근 요청 리소스
    # access_plugin_data - 접근 요청 플러그인 데이터를 수정할 수 있도록 허용
    #
    # session            - 세션 재생 기록
    # session_tracker    - 활성 세션
    # ssh_session        - 활성 세션 페이지를 보는 것이 허용됩니다.
    # instance           - Teleport 인스턴스
    # event              - 구조적 감사 로깅 이벤트
    #
    #
    # lock                  - 잠금 리소스.
    # network_restrictions  - SSH 세션에 대한 제한
    #
    # auth_server           - Auth 서비스 리소스
    # proxy                 - 프록시 서비스 리소스
    # node                  - SSH 노드 리소스
    # app                   - 애플리케이션 리소스
    # db                    - 데이터베이스 리소스
    # kube_cluster          - Kubernetes 클러스터 리소스
    # token                 - 프로비저닝 토큰 리소스
    # cert_authority        - 인증기관 리소스
    #
    # cluster_name              - 클러스터 이름을 포함하는 리소스.
    # cluster_config            - 클러스터 수준 설정을 보유한 리소스
    # cluster_auth_preference   - 이 클러스터에 대한 인증 유형
    # session_recording_config  - 세션 기록 설정을 위한 리소스
    # cluster_audit_config      - 클러스터 감사 구성을 보유한 리소스
    # cluster_networking_config - 클러스터 네트워킹 구성을 보유한 리소스

    rules:
      - resources: [role]
        verbs: [list, create, read, update, delete]
      - resources: [auth_connector]
        verbs: [list, create, read, update, delete]
      - resources: [session]
        verbs: [list, read]
      - resources: [trusted_cluster]
        verbs: [list, create, read, update, delete]
      - resources: [event]
        verbs: [list, read]
      - resources: [user]
        verbs: [list, create, read, update, delete]
      - resources: [token]
        verbs: [list, create, read, update, delete]

  # deny 섹션은 'allow' 섹션과 동일한 형식을 사용합니다.
  # 거부 규칙은 항상 허용 규칙을 무시합니다.
  deny: {}

역할 옵션

역할은 사용자가 시작한 세션에 대해 특정 제한을 정의할 수 있습니다. 아래 표는 사용자가 여러 역할을 할당받았을 때 각 옵션의 동작을 문서화합니다:

옵션설명다중 역할 동작
max_session_ttl사용자의 SSH 인증서의 최대 TTL(유효 기간)가장 짧은 TTL이 우선
forward_agentSSH 에이전트 포워딩 허용논리적 "OR", 즉 어떤 역할이든 에이전트 포워딩을 허용하면 허용
port_forwardingTCP 포트 포워딩 허용논리적 "OR", 즉 어떤 역할이든 포트 포워딩을 허용하면 허용
ssh_file_copySCP/SFTP 허용논리적 "AND", 즉 모든 역할이 파일 복사를 허용해야 허용
client_idle_timeout비활성 간격 후 활성 세션을 강제로 종료가장 짧은 타임아웃 값이 우선
disconnect_expired_cert클라이언트 인증서가 만료될 때 활성 세션을 강제로 종료논리적 "OR", 즉 최소한 하나의 역할이 세션 종료를 요구하면 평가 결과가 "예"
max_sessions텔레포트를 통해 단일 SSH 연결에서 설정할 수 있는 총 세션 채널 수가장 낮은 값이 우선.
enhanced_recordingBFP 기반 세션 레코더가 기록해야 할 이벤트를 표시
permit_x11_forwarding사용자가 OpenSSH 클라이언트 및 서버에 대해 X11 포워딩을 활성화할 수 있도록 허용
device_trust_mode이 역할이 할당된 사용자에게 인증된 장치 접근 강제 (required, optional, off). 역할의 allow 필드에 있는 리소스에만 적용됩니다.
require_session_mfa사용자 로그인 세션에 대한 세션별 MFA 또는 PIV 하드웨어 키 제한 강제 (no, yes, hardware_key, hardware_key_touch). 역할의 allow 필드에 있는 리소스에만 적용됩니다.세션별 MFA, 논리적 "OR", 즉 최소한 하나의 역할이 세션 MFA를 요구하면 평가 결과가 "예"
mfa_verification_interval연속 MFA 검증 사이의 최대 기간 정의가장 짧은 간격이 우선
lock잠금 모드 (strict 또는 best_effort)충돌 시 strict가 우선
request_access엔터프라이즈 전용 접근 요청 전략 (optional, always 또는 reason)
request_prompt접근 요청 "reason" 필드를 위한 프롬프트
max_connections엔터프라이즈 전용 텔레포트를 통해 시작할 수 있는 동시에 연결 세션의 제한가장 낮은 값이 우선.
max_kubernetes_connections사용자당 동시 쿠버네티스 세션의 최대 수를 정의
record_session세션 레코딩 모드 정의합니다.가장 엄격한 값이 우선.
desktop_clipboard데스크톱 세션의 클립보드 공유 허용논리적 "AND", 즉 모든 역할이 클립보드 공유를 허용해야 "예"로 평가됩니다.
pin_source_ipSSH 인증서에 대한 소스 IP 고정을 활성화합니다.논리적 "OR", 즉 최소한 하나의 역할이 세션 종료를 요구하면 평가 결과가 "예"
cert_extensionsSSH 인증서에 포함될 확장자를 지정합니다.
create_host_user_mode호스트에서 사용자가 자동으로 생성되도록 허용합니다.논리적 "AND", 즉 서버와 일치하는 모든 역할이 호스트 사용자 생성 (off, keep, insecure-drop)을 지정하는 경우, 모든 역할이 지정한 옵션에 따라 평가됩니다. insecure-drop 또는 keep를 지정한 일부 역할이 있는 경우에는 keep로 평가됩니다.
create_db_user_mode데이터베이스 사용자 자동 프로비저닝 허용. 옵션: off (데이터베이스 사용자 자동 프로비저닝 비활성화), keep (세션 종료 시 사용자 비활성화, 역할 제거 및 잠금), best_effort_drop (세션 종료 시 사용자를 드롭하려고 시도, 성공하지 못할 경우 비활성화로 대체).논리적 "OR", 즉 어떤 역할이든 데이터베이스 사용자 자동 프로비저닝을 허용하면 허용

사전 설정된 역할

텔레포트는 여러 개의 사전 설정된 역할을 제공합니다:

역할설명
access클러스터 리소스에 대한 접근을 허용합니다.
editor클러스터 구성 설정을 편집할 수 있습니다.
auditor클러스터 이벤트, 감사 로그를 읽고 세션 기록을 재생할 수 있습니다.
requester사용자에게 접근 요청을 생성할 수 있는 엔터프라이즈 전용 역할입니다.
reviewer접근 요청을 검토할 수 있는 엔터프라이즈 전용 역할입니다.
group-access모든 사용자 그룹에 대한 접근을 허용합니다.
device-admin신뢰할 수 있는 장치를 관리하는 데 사용됩니다.
device-enroll사용자에게 장치 등록 권한을 부여하는 데 사용됩니다.
require-trusted-device리소스에 대한 접근을 위해 신뢰할 수 있는 장치가 필요합니다.
terraform-providerTeleport Terraform 공급자가 모든 지원되는 Teleport 리소스를 구성할 수 있도록 허용합니다.

역할 버전

현재 지원되는 역할 버전은 v3, v4, v5, v6v7입니다.

v4 및 그 이상의 역할은 v3와 완전히 이전 호환됩니다. 유일한 차이점은 명시적으로 설정되지 않은 경우 역할에 적용되는 기본값입니다. 또한, v5 또는 그 이상의 버전을 가진 역할은 Moderated Sessions를 사용해야 합니다.

Labelv3 기본값v4 및 그 이상의 기본값
node_labels[{"*": "*"}] 역할에 로그인이 있는 경우, 그렇지 않으면 [][]
app_labels[{"*": "*"}][]
kubernetes_labels[{"*": "*"}][]
db_labels[{"*": "*"}][]

역할 v6는 쿠버네티스 리소스에 대한 세밀한 제어를 가능하게 하는 새로운 필드 kubernetes_resources를 도입했습니다. 자세한 내용은 Kubernetes RBAC를 참조하세요.

Versionkubernetes_resources
v3, v4v5 기본[{"kind":"pod", "name":"*", "namespace":"*", "verbs": ["*"]}]
v6 기본[]
v7 기본[{"kind":"*", "name":"*", "namespace":"*", "verbs": ["*"]}]

인프라 리소스를 위한 RBAC

텔레포트 역할은 사용자가 접근할 수 있는 리소스(예: 애플리케이션, 서버 및 데이터베이스)를 정의합니다. 이는 역할 정의에서 허용/거부 레이블을 구성하고 리소스를 레이블링함으로써 작동합니다.

다음 사용 사례를 고려해 보세요:

인프라는 environment=productionenvironment=staging과 같은 레이블을 사용하여 스테이징/프로덕션 환경으로 나뉩니다. 하나의 환경에만 접근할 수 있는 역할을 생성할 수 있습니다. 예를 들어, environment=staging 레이블에 대한 허용 규칙이 있는 인턴 역할을 생성한다고 가정해 보겠습니다.

예시

아래 역할은 "workload=database" 또는 "workload=backup" 레이블도 가진 모든 노드에 대한 접근을 허용합니다.

다른 노드에 대한 접근은 거부됩니다.

kind: role
version: v5
metadata:
  name: example-role
spec:
  allow:
    node_labels:
      'env': 'stage'

  deny:
    node_labels:
      # 여러 레이블은 "or" 연산으로 해석됩니다. 이 경우,
      # 텔레포트는 'workload=database' 또는
      # 'workload=backup'라는 레이블이 있는 모든 노드에 대한 접근을 거부합니다.
      'workload': ['database', 'backup']

텔레포트는 여러 개의 레이블 항목을 논리적 "AND" 연산으로 처리합니다. 예를 들어, 이 항목은 env: prod 레이블이 있는 데이터베이스와 region 레이블이 us-west-1 또는 eu-central-1인 데이터베이스와 일치합니다:

    db_labels:
      'env': 'prod'
      'region': ['us-west-1', 'eu-central-1']
동적 RBAC

리소스 레이블은 동적일 수 있으며, 실행 가능한 출력을 통해 런타임에 결정됩니다. 이 경우, "권한이 작업에 따라 따라간다" 정책을 구현할 수 있습니다(예: PostgreSQL이 실행되고 있는 서버는 "DBA" 그룹의 구성원에게만 자동으로 접근 가능해짐).

확장된 레이블 매칭 구문

다음은 다양한 정규 표현식을 사용하여 더 복잡한 필터링의 몇 가지 예입니다.

kind: role
version: v5
metadata:
  name: example-role
spec:
  allow:
    node_labels:
      # 리터럴 문자열:
      'environment': 'test'
      # 와일드카드 ('*')는 "모든 노드"를 의미합니다.
      '*': '*'
      # 대체 옵션 목록:
      'environment': ['test', 'staging']
      # 정규 표현식도 지원되며, 예를 들어 목록 예와
      # 동일한 의미로 표현할 수 있습니다:
      'environment': '^test|staging$'

레이블 표현식

Warning

레이블 표현식은 텔레포트 버전 13.1.1부터 사용 가능합니다. 레이블 표현식을 사용하기 전에 텔레포트 클러스터의 모든 구성 요소를 버전 13.1.1 이상으로 업그레이드해야 합니다. 여기에는 인증 서비스와 모든 텔레포트 에이전트가 포함됩니다.

텔레포트 역할은 다음과 같은 경우에 자원 레이블과 조건부 표현식으로 매칭을 지원합니다:

  • OR 및 AND 연산자로 논리를 결합합니다.
  • 레이블 키에 대해 매칭을 수행합니다.
  • 부정 매칭을 구현합니다.

다음 예시는 env=staging로 레이블이 지정된 노드 또는 사용자의 teams 특성 중 하나가 레이블된 노드에 접근을 허용하는 역할입니다:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    node_labels_expression: |
      labels["env"] == "staging" ||
      contains(user.spec.traits["teams"], labels["team"])

<kind>_labels_expression 필드는 <kind>_labels 필드와 동일한 목적을 가지고 있지만 레이블 매처 대신 조건부 표현식을 지원합니다. 다음 역할 spec.allowspec.deny 조건의 필드에서 사용할 수 있습니다:

  • node_labels_expression
  • app_labels_expression
  • cluster_labels_expression
  • kubernetes_labels_expression
  • db_labels_expression
  • db_service_labels_expression
  • windows_desktop_labels_expression
  • group_labels_expression

자세한 설명은 조건부 언어 가이드를 확인하세요.

일반적으로 하나의 역할에는 <kind>_labels 또는 <kind>_labels_expression 중 하나만 사용하고 싶지만 둘 다 지정할 수도 있습니다. 거부 규칙에서 둘 다 있을 경우 매칭은 탐욕적이며, 어느 하나라도 일치하면 접근이 거부됩니다. 허용 규칙에서는 매칭이 탐욕적이지 않으며, 둘 다 설정된 경우 접근이 허용되려면 둘 다 일치해야 합니다.

동적 텔레포트 리소스를 위한 RBAC

RBAC는 팀이 텔레포트 사용자에게 사용 가능한 리소스를 제한할 수 있게 합니다. 예를 들어, 일반 사용자가 SSO (auth_connector)를 편집하거나 새로운 역할 (role)을 생성 및 편집하는 것을 원치 않는 경우 유용합니다.

RBAC 리소스를 수정하기 위한 규칙은 리소스와 동사를 포함하는 두 부분으로 구성됩니다. 다음은 SSH sessions 리소스에 대해 적용된 list 동사를 설명하는 allow 규칙 예시입니다. 즉, "이 역할의 사용자가 활성 SSH 세션의 목록을 볼 수 있도록 허용합니다"라는 의미입니다.

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

이 규칙이 역할 정의의 deny 섹션에 선언된 경우 사용자에게 활성 세션 목록을 가져오는 것을 금지할 것입니다. 아래의 예시 역할 구성에서 사용할 수 있는 모든 리소스와 동사 목록을 볼 수 있습니다.

아래는 일반적으로 사용되는 규칙을 설명하는 allow 섹션의 예시입니다. 각 규칙에는 사용자가 실행할 수 있는 CRUD 작업과 텔레포트 리소스의 목록이 포함되어 있습니다:

allow:
  rules:
    # 텔레포트 서버 접근 노드를 관리하는 CRUD 옵션
    - resources:
        - node
      verbs: [list, create, read, update, delete]
    - resources:
        - app
      verbs: [list, create, read, update, delete]
    - resources:
        - kube_service
      verbs: [list, create, read, update, delete]
    - resources:
        - kube_cluster
      verbs: [list, create, read, update, delete]
    - resources:
        - db
      verbs: [list, create, read, update, delete]
    - resources:
        - windows_desktop
      verbs: [list, create, read, update, delete]
    - resources:
        - role
      verbs: [list, create, read, update, delete]
    # 인증 커넥터는 SSO 커넥터라고도 불립니다.
    - resources:
        - auth_connector
      verbs: [list, create, read, update, delete]
    # 세션: 세션 녹화에 대한 접근 제공.
    # 예를 들어 세션 읽기가 거짓이면 사용자는 녹화를 재생할 수 없습니다.
    # "list"를 제한하고 "read"를 허용할 수 있습니다(이 경우 사용자는 세션 ID를 알고 있다면 `tsh play`를 사용하여 세션을 재생할 수 있습니다).
    - resources:
        - session
      verbs: [list, read]
    - resources:
        - trusted_cluster
      verbs: [list, create, read, update, delete]
    # 이벤트: 사용자가 감사 로그 및 세션 녹화를 볼 수 있는지 여부를 결정합니다.
    - resources:
        - event
      verbs: [list, read]
    - resources:
        - user
      verbs: [list, create, read, update, delete]
    - resources:
        - token
      verbs: [list, create, read, update, delete]

토큰 리소스에 대한 접근 허용

토큰 생성이 허용되는 역할을 구성하면 해당 역할에 할당된 사용자는 텔레포트 리소스의 모든 유형을 프로비저닝하기 위해 토큰을 생성할 수 있습니다. 예를 들어, 다음 구성을 통해 할당된 사용자가 서버에 등록할 수 있도록 하는 역할을 생성할 수 있습니다:

kind: role
version: v7
metadata:
  name: enroll-servers
spec:
  allow:
    node_labels:
      'env': 'us-lab'
    rules:
      - resources: [token]
        verbs: [list, create, read, update, delete]
  deny: {}

이 권한을 통해 이 역할에 할당된 사용자는 서버, 애플리케이션 또는 데이터베이스를 등록하기 위해 토큰을 생성할 수 있습니다. 루트 클러스터와 새로운 텔레포트 프록시 서비스 간의 신뢰 관계를 설정하거나 새로운 리프 클러스터를 추가할 수 있습니다.

토큰 리소스는 특정 컨텍스트(예: 노드 또는 신뢰할 수 있는 클러스터)에 국한되지 않기 때문에 토큰 권한을 제공하는 역할은 관리 역할로 간주해야 합니다. 특히 구성 및 클러스터 상태의 예상치 못한 변경을 방지하기 위해 token 리소스에 대한 createupdate 권한을 부여하는 allow 규칙을 구성하지 않는 것이 좋습니다.

세션에 대한 RBAC

공유 세션세션 녹화에 대한 접근을 더욱 제한할 수 있습니다. 아래 예시는 세션을 생성한 사용자만 세션 접근 권한을 제한하는 방법을 보여줍니다.

사전 설정된 감사인 역할

이 역할이 효과를 보려면 사용자가 사전 설정된 auditor 역할과 같이 더 허용적인 역할을 갖지 않도록 해야 합니다. 이 역할은 모든 이벤트, 세션 및 세션 녹화에 대한 접근을 허용합니다.

세션 녹화에 대한 제한된 접근을 위한 역할:

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

활성 세션에 대한 제한된 접근을 위한 역할:

version: v5
kind: role
metadata:
  name: only-own-ssh-sessions
spec:
  allow:
    rules:
    # 텔레포트는 사용자의 세션과 사용자가 참여할 수 있는 세션에 대한 접근을 기본적으로 허용합니다. 
    # 이는 모든 세션을 볼 수 있게 합니다.
    - resources: [session_tracker]
      verbs: ['*']
  deny:
    rules:
    # ...그리고 접근을 제한하는 거부 규칙을 통해.
    # 거부 규칙이 허용 규칙보다 우선하므로 결과적으로 사용자는 자신의 활성 세션만 볼 수 있습니다.
    - resources: [session_tracker]
      verbs: [list, read, update, delete]
      where: '!contains(session_tracker.participants, user.metadata.name)'

역할 템플릿

텔레포트 역할 리소스에서 특정 필드는 사용자의 접근을 구성하기 위해 함수 및 변수를 사용할 수 있습니다. 필드에 사용할 수 있는 함수 및 변수는 필드가 구성하는 접근 제어에 따라 다릅니다.

인프라 리소스 접근을 위한 템플릿 표현식

사용자가 텔레포트로 프록시된 인프라 리소스(예: 데이터베이스 또는 쿠버네티스 클러스터)에 인증을 시도할 때 텔레포트는 사용자의 역할에서:

  • 사용자가 리소스에 연결할 수 있는지 여부
  • 사용자 인증 시 어떤 주체를 대리할 수 있는지(예: 리눅스 서버 로그인 및 쿠버네티스 그룹)를 결정합니다.

필드

다음 역할 필드는 사용자가 인프라 리소스에 접근할 수 있는 것을 제어합니다. 이 모든 필드는 텔레포트 역할 리소스의 allowdeny 섹션 내에 있습니다.

텔레포트에 의해 등록된 리소스에 대한 레이블:

  • app_labels
  • cluster_labels
  • db_labels
  • db_service_labels
  • kubernetes_labels
  • node_labels
  • windows_desktop_labels

인프라 리소스에서 사용자가 대리할 수 있는 주체:

  • aws_role_arns
  • azure_identities
  • db_names
  • db_roles
  • db_users
  • desktop_groups
  • gcp_service_accounts
  • host_groups
  • host_sudoers
  • kubernetes_groups
  • kubernetes_users
  • logins
  • windows_desktop_logins

사용자가 대리할 수 있는 텔레포트 주체:

  • impersonate.rules
  • impersonate.users

함수

다음 함수는 인프라 리소스의 주체에 대한 접근을 관리하는 역할 필드에서 사용할 수 있습니다:

함수설명
{{email.local(variable)}}이메일 주소의 로컬 부분을 추출합니다.
{{regexp.replace(variable, expression, replacement)}}변수 내에서 표현식의 모든 일치를 찾아 대체 문자열로 바꿉니다.

특성

인프라 리소스에 대한 접근을 구성하는 필드의 경우, 텔레포트는 인증하는 사용자의 데이터로 다음 특성을 대체합니다. 이것은 로컬 사용자 데이터베이스와 사용자의 외부 단일 로그인 공급자에서 가져옵니다.

변수설명
{{internal.aws_role_arns}}사용자가 허용된 AWS 역할 ARNS의 목록입니다.
{{internal.azure_identities}}사용자가 접근할 수 있는 텔레포트에 정의된 Azure ID의 목록을 반환합니다. Azure ID는 특정 사용자에게 설정되거나 역할에 정의될 수 있습니다.
{{internal.db_names}}사용자가 허용된 모든 데이터베이스 이름의 목록입니다.
{{internal.db_roles}}사용자가 허용된 모든 데이터베이스 역할의 목록입니다.
{{internal.db_users}}사용자가 허용된 모든 데이터베이스 사용자의 목록입니다.
{{internal.gcp_service_accounts}}사용자의 GCP 서비스 계좌의 목록입니다.
{{internal.jwt}}앱 접근에 사용되는 JWT 헤더입니다.
{{internal.kubernetes_groups}}사용자가 허용된 쿠버네티스 그룹의 목록입니다.
{{internal.kubernetes_users}}사용자가 허용된 쿠버네티스 사용자의 목록입니다.
{{internal.logins}}텔레포트의 로컬 사용자 데이터베이스 및 루트 클러스터의 로그인에서 저장된 값으로 대체됩니다.

로컬 사용자의 경우, 텔레포트는 tctl users add [user] <허용 로그인> 명령에서 사용되는 "허용 로그인" 매개변수로 대체합니다.

역할이 신뢰할 수 있는 클러스터의 리프 클러스터 내에 있을 경우, 텔레포트는 루트 클러스터에서 로그인하여 사용자가 로컬 사용자이든 SSO 공급자를 통해 오든 상관없이 루트 클러스터에서 로그인하는 목록으로 대체합니다.

예를 들어, 사용자가 루트 클러스터에서 ubuntu 로그인을 가지고 있는 경우, 리프 클러스터에서 internal.logins는 이 변수로 ubuntu로 대체됩니다.
{{internal.windows_logins}}사용자가 허용된 Windows 로그인의 목록입니다.
{{external.xyz}}외부 SSO 공급자에서 받은 값으로 대체됩니다. SAML을 사용하는 경우, 이 값은 "xyz" 주장 값으로 확장됩니다. OIDC의 경우, 변수는 "xyz" 주장의 값으로 확장됩니다. 이와 관련된 더 많은 정보는 텔레포트 역할의 다음 섹션을 참조하세요.

텔레포트 역할의 내부 특성 참조

internal 특성 네임스페이스에는 위 표에 포함된 정확한 내부 특성 이름만 포함됩니다. 로컬 텔레포트 사용자에 대한 이러한 특성은 사용자 리소스spec.traits 필드에 설정할 수 있습니다. 이러한 특성 이름은 SSO 사용자에 대해서도 IdP에서 받은 속성이나 주장에 포함된 경우 설정할 수 있습니다.

internal 특성은 사전 설정된 역할 accessrequire-trusted-device에서 사용자의 특성을 기반으로 리소스에 대한 접근을 허용하기 위해 참조됩니다. 외부 특성은 사전 설정된 역할에서 절대 참조되지 않습니다(사전 설정된 역할을 수동으로 편집하지 않는 한).

역할 내에서 내부 특성을 참조하는 방법은 다음과 같습니다:

logins:
  - '{{internal.logins}}'
Warning

하위 호환성을 위해 일부 내부 특성은 리프 클러스터와 루트 클러스터에서 확장될 때 다를 수 있습니다. 리프 클러스터에서는 logins, kubernetes_groups, kubernetes_users, db_names, db_users, 및 aws_role_arns 특성이 사용자 인증 시 발급되는 인증서에 인코딩된 모든 값을 포함하는 전체 세트로 설정됩니다. 예를 들어, 사용자가 리프 클러스터에 접근할 때 internal.logins 특성은 사용자에게 허용된 SSH 로그인 목록의 전체 목록으로 설정됩니다. 이 목록은 루트 클러스터에서 사용자의 internal.logins 특성에 포함된 값과도 호환됩니다.

텔레포트 역할의 외부 특성 참조

로컬 텔레포트 사용자에 대한 external 특성 네임스페이스에는 사용자 리소스spec.traits 필드에서 모든 값이 포함됩니다. 이는 사용자 정의 특성 이름과 위의 internal 특성과 일치하는 이름을 포함합니다. 즉, {{internal.logins}}{{external.logins}}는 둘 다 logins 특성을 참조하는 유효한 방법이지만, groups와 같은 사용자 정의 특성은 {{external.groups}}로만 참조될 수 있습니다.

사용자가 단일 로그인 공급자(IdP)를 통해 텔레포트에 인증할 때, 텔레포트는 IdP로부터 받는 속성을 사용하여 external 특성을 채웁니다. 예를 들어, 응답에서 다음 SAML 어설션 속성이 있다고 가정해 보겠습니다:

<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname">
        <AttributeValue>firstname.lastname</AttributeValue>
</Attribute>

... 다음과 같이 역할 내에서 참조할 수 있습니다:

logins:
   - '{{external["http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]}}'

역할 템플릿 내에서 다음 두 형식을 사용하여 이 변수를 참조할 수 있습니다. 여기서 trait는 특성의 이름입니다:

  • 점 구문: {{external.trait}}
  • 괄호 구문: {{external["trait"]}}

텔레포트는 위에서 설명한 템플릿 변수를 SAML 속성 또는 OIDC 주장의 값으로 확장합니다.

특성이 문자로 시작하고 문자, 숫자 및 밑줄만 포함된 경우에는 점 구문을 사용하여 외부 특성을 참조할 수 있습니다. 그렇지 않으면 괄호 구문을 사용하여 특성을 지정해야 합니다.

SSO 솔루션에서 사용할 수 있는 일반적인 외부 특성의 예는 다음과 같습니다:

  • {{external.logins}}
  • {{external.username}}
  • {{external.env}}

텔레포트는 외부 변수를 문자열 또는 문자열 목록으로만 확장할 수 있습니다. OIDC 기반 SSO 솔루션을 사용하는 경우 지원되는 데이터 유형의 값을 포함하도록 IdP를 구성했는지 확인하세요.

IdP의 문서를 참조하여 사용 가능한 주장 및 속성 목록 전부를 확인하세요.

접근 요청 템플릿 함수

다음 변수 및 함수는 사용자가 접근 요청을 제출하고 검토할 수 있는 권한을 보다 세밀하게 제어할 수 있습니다.

필드

다음 필드에서 접근 요청 템플릿 함수를 사용할 수 있습니다. 이러한 필드를 allow 규칙 또는 deny 규칙 내에 포함할 수 있습니다:

  • request.search_as_roles
  • request.roles
  • review_requests.preview_as_roles
  • review_requests.roles
  • review_requests.where

함수

접근 요청은 다음 역할 템플릿 함수를 지원합니다:

함수설명
{{regexp.match(regexp)}}정규 표현식이 사용자의 역할과 일치할 경우 true를 반환합니다.
{{regexp.not_match(regexp)}}정규 표현식이 사용자의 역할과 일치하지 않을 경우 true를 반환합니다.

정규 표현식은 glob 스타일의 와일드카드(* 문자)와 Go 스타일의 정규 표현식을 지원합니다. 표현식이 ^ 문자로 시작하고 $ 문자로 끝나면 텔레포트는 이를 정규 표현식으로 평가합니다. 그렇지 않으면 와일드카드 표현식으로 평가합니다. 와일드카드는 0개 이상의 문자의 모든 시퀀스와 일치합니다.

필터 필드

이 가이드 내에서 wherefilter 조건에 사용되는 필드에 대한 설명입니다:

필드설명
user.spec.roles사용자에게 할당된 역할 목록
session.participants세션 녹화에서 참가자의 목록
session_tracker.participants세션에서 참가자의 목록
user.metadata.name사용자의 이름

자세한 내용은 조건부 언어 가이드를 참조하세요.

Teleport 원문 보기