인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!
Teleport 접근 제어 참조
이 가이드는 Teleport 역할을 사용하여 Teleport 클러스터에서 역할 기반 접근 제어(RBAC)를 관리하는 방법을 보여줍니다.
Teleport 역할은 두 개의 규칙 목록으로 접근을 관리합니다: allow
규칙과 deny
규칙. 접근 규칙을 선언할 때 다음 사항을 염두에 두십시오:
- 기본적으로 아무 것도 허용되지 않습니다.
- deny 규칙이 먼저 평가되며 우선권을 가집니다.
- Access Lists를 통해 부여된 역할에서는 deny 규칙을 피해야 합니다.
다음 중 하나를 사용하여 Teleport 역할 및 기타 동적 리소스를 관리할 수 있습니다:
- Teleport 웹 UI
tctl
클라이언트 도구- Teleport Terraform 프로바이더
- Teleport Kubernetes 운영자
- 커스텀 API 클라이언트
동적 리소스 관리에 대한 자세한 내용은 동적 리소스 가이드를 참조하십시오.
다음 명령어를 실행하여 로컬 워크스테이션에서 클러스터의 모든 역할을 확인할 수 있습니다:
tsh를 사용하여 클러스터에 로그인하여 로컬 머신에서 tctl을 사용할 수 있습니다.
tsh login --user=myuser --proxy=mytenant.teleport.shtctl get roles
경고
운영 인스턴스, 환경 및/또는 설정을 영구 수정하기 전에 백업하는 것은 모범 사례로 권장됩니다. 이를 통해 필요할 경우 기존 상태로 롤백할 수 있습니다.
예제 역할 사양
여기 전체 역할 사양이 있습니다:
kind: 역할
version: v7
metadata:
name: 예제
description: 이것은 예제 역할입니다.
spec:
# 사용자에게 여러 개의 비기본 충돌 옵션이 있는 경우 연결 옵션을 지정합니다.
# 텔레포트는 가장 허용되지 않는 값을 선택합니다.
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 검증 사이에 경과할 수 있는 최대 기간을 정의합니다.
# 이 변수는 사용자가 주기적으로 자신의 신원을 검증하라는 프롬프트를 받을 수 있도록 하여,
# tsx 프록시 * 파생물을 사용할 때 재인증 없이 오랜 세션을 방지하여 보안을 강화합니다.
mfa_verification_interval: 1h
# lock은 이 역할을 가진 사용자의 잠금 모드를 설정합니다.
# 유효한 값은 'strict' 또는 'best_effort'입니다.
lock: strict
# 기업 전용 request_access 필드는 'optional', 'always' 또는 'reason'입니다. 항상 또는 이유로 설정하면,
# 이는 tsh 또는 웹 UI 클라이언트에 액세스 요청을 항상 생성하도록 지시합니다. 'reason'으로 설정하면
# 사용자가 액세스 요청을 생성하는 이유를 제출해야 합니다.
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(인증 서비스)에서 'off'로 설정되어 있거나,
# 클러스터의 session_recording_config 리소스가 'mode: off'로 설정되어 있으면 데스크탑 세션은 절대 기록되지 않습니다.
desktop: true
# 선택 사항: 프로토콜 특정 모드가 설정되지 않을 경우 사용할 기본 세션 기록 모드입니다.
default: best_effort|strict
# 선택 사항: SSH 세션(텔레포트 서버 접근)에 대한 세션 기록 모드입니다. 설정되지 않은 경우 기본값이 사용됩니다.
ssh: best_effort|strict
# 클립보드 공유가 원격 데스크탑과 함께 허용되어야 하는지 여부를 지정합니다.
# (지원되는 브라우저가 필요합니다). 지정하지 않으면 기본값은 true입니다.
# 사용자의 역할 중 하나라도 클립보드를 비활성화했다면 비활성화됩니다.
desktop_clipboard: true
# 로컬 머신에서 원격 데스크탑으로 디렉터리 공유가 허용되어야 하는지 여부를 지정합니다.
# (지원되는 브라우저가 필요합니다). 지정하지 않으면 기본값은 true입니다.
# 사용자의 역할 중 하나라도 디렉터리 공유를 비활성화했다면 비활성화됩니다.
desktop_directory_sharing: 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
# 자동 프로비전된 SSH 사용자의 기본 셸을 설정합니다. 셸에 대한 절대 경로 또는 시스템 PATH를 통해
# 도달할 수 있는 이름 모두 유효한 값입니다. create_host_user_mode가 off로 설정되지 않을 경우에만 적용됩니다.
create_host_user_default_shell: bash
# 이 역할이 자동 데이터베이스 사용자 프로비저닝을 요구해야 하는지 여부를 제어합니다.
# 옵션: 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']
# 정규 표현식은 ^로 시작하고 $로 끝납니다.
# 텔레포트는 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` 를 실행할 수 있도록 허용합니다.
# sudoers 항목은 로그인한 사용자 이름으로 접두사가 붙습니다.
"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-*'
# 정규 표현식은 ^로 시작하고 $로 끝납니다.
# 텔레포트는 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:
# 리소스 종류. 텔레포트는 현재 다음을 지원합니다:
# - * (모든 리소스)
# - 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-]+$'
# 사용자가 리소스에 대해 수행할 수 있는 동작입니다.
# 텔레포트는 현재 다음을 지원합니다:
# - * (모든 동작)
# - 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-*'
# 정규 표현식은 ^로 시작하고 $로 끝납니다.
# 텔레포트는 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 콘솔에 접근할 때 AWS 역할을 수임할 수 있도록 허용합니다.
# UI 또는 AWS API를 사용하여 CLI
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'
# Identity Center 통합을 위한 AWS 계정 및 권한 세트 바인딩
account_assignments:
- # AWS identity center 계정 ID
account: "<account_id>"
# AWS에서의 권한 세트 이름
name: AdministratorAccess
# 권한 세트 ARN
permission_set: arn:aws:sso:::permissionSet/ssoins-1234/ps-5678 # 권한 세트 ARN
# impersonate를 사용하면 이 역할을 가진 사용자가 아래 표현과 일치하는 다른 사용자 및 역할의 이름으로 인증서를 발급할 수 있습니다.
impersonate:
users: ['*']
roles: ['jenkins']
# where는 선택적 조건부로, 사용자와 역할의 일치를 더욱 제한하는 조건입니다.
where: >
contains(user.spec.traits["group"], impersonate_role.metadata.labels["group"]) &&
contains(user.spec.traits["group"], impersonate_user.metadata.labels["group"])
# review_requests는 이 역할을 가진 사용자가 액세스 요청을 승인 또는 거부할 수 있도록 허용합니다. (기업 전용)
review_requests:
# 리뷰어는 여기에 나열된 역할에 대한 액세스 요청을 보고 승인 또는 거부할 수 있습니다.
roles: ['dbadmin']
# 리뷰어는 리소스 접근 요청을 검토할 때 preview_as_roles에 나열된 역할에 대해 접근 가능한 리소스에 대한 세부 정보를 미리 볼 수 있습니다.
preview_as_roles: ['dbadmin']
# request는 사용자가 아래 표현과 일치하는 역할을 요청할 수 있도록 허용합니다.
request:
# 'roles' 목록은 리터럴과 와일드카드 일치자를 혼합할 수 있습니다.
roles: ['common', 'dev-*']
# 'search_as_roles'는 사용자에게 나열된 역할에 의해 접근할 수 있는 리소스를 검색하고 요청할 수 있도록 허용합니다. (기업 전용)
search_as_roles: ['access']
# 'kubernetes_resources'는 사용자가 어떤 종류의 Kubernetes 리소스를 요청할 수 있는지를 제한합니다. 아래 예에서는 사용자가 오직 Kubernetes 네임스페이스만 요청할 수 있습니다.
# 기본값(아무것도 정의되지 않을 경우)은 모든 Kubernetes 리소스나 전체 클러스터에 대한 접근 요청을 허용합니다.
kubernetes_resources:
- kind: "namespace"
# 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 커넥터에서와 동일하게 작동하지만,
# 매핑되는 역할도 일치자일 수 있는 추가 이점이 있습니다.
#
# 이 예제는 사용자의 클레임에서 동적 매핑을 허용하는 텔레포트의 정규 표현식 지원을 활용합니다.
# 아래 매핑은 'projects: product-(.*)'와 일치하는 클레임을 가진 사용자가 '$1-admin'에 해당하는 역할을 요청할 수 있음을 나타냅니다.
# 예: 'projects: product-foo' 클레임은 사용자가 'foo-admin' 역할을 요청할 수 있게 합니다.
claims_to_roles:
- claim: 'projects'
# 선행 'product-'가 있는 모든 그룹 이름과 일치합니다.
value: '^product-(.*)$'
# 값 캡처에서 역할 이름을 생성합니다.
roles: ['$1-admin']
# 텔레포트는 보류 중인 액세스 요청에 주석을 첨부할 수 있습니다. 이러한
# 주석은 리터럴일 수 있으며, 변수 보간 표현식이 될 수 있으며,
# 효과적으로 외부 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"
# 사용자 요청에 SPIFFE ID와 함께 포함될 수 있는 IP SAN입니다.
# 이 블록의 필드는 선택적이며 생략하면
# 사용자가 IP SAN과 함께 SVID를 요청할 수 없습니다.
ip_sans: ["10.0.0.100/32"]
# 사용자 요청에 SPIFFE ID와 함께 포함될 수 있는 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 - 텔레포트 인스턴스
# event - 구조화된 감사 로그 이벤트
#
#
# lock - 잠금 리소스
# network_restrictions - SSH 세션에 대한 제한 사항
#
# auth_server - 인증 서비스 리소스
# 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 규칙은 항상 allow 규칙을 무시합니다.
deny: {}
역할 옵션
역할은 사용자가 시작한 세션에 대한 특정 제한을 정의할 수 있습니다. 아래 표는 다수의 역할이 사용자에게 할당되었을 때 각 옵션의 동작을 문서화합니다:
옵션 | 설명 | 다중 역할 동작 |
---|---|---|
max_session_ttl | 사용자의 SSH 인증서의 최대 TTL(생존 시간) | 가장 짧은 TTL이 우선합니다 |
forward_agent | SSH 에이전트 포워딩 허용 | 논리적 "OR", 즉 어떤 역할이라도 에이전트 포워딩을 허용하면 허용됩니다 |
port_forwarding | TCP 포트 포워딩 허용 | 논리적 "OR", 즉 어떤 역할이라도 포트 포워딩을 허용하면 허용됩니다 |
ssh_file_copy | SCP/SFTP 허용 | 논리적 "AND", 즉 모든 역할이 파일 복사를 허용해야 허용됩니다 |
client_idle_timeout | 유휴 간격 후 활성 세션을 강제 종료 | 가장 짧은 타임아웃 값이 우선합니다; 즉, 가장 제한적인 값이 선택됩니다 |
disconnect_expired_cert | 클라이언트 인증서가 만료되면 활성 세션을 강제 종료 | 논리적 "OR", 즉 한 역할이라도 세션 종료를 요구하면 "예"로 평가됩니다 |
max_sessions | Teleport를 통해 단일 SSH 연결에서 설정할 수 있는 총 세션 채널 수 | 가장 낮은 값이 우선합니다. |
enhanced_recording | BFP 기반 세션 녹화기가 기록해야 할 이벤트를 나타냅니다 | |
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 | 접근 요청 "이유" 필드를 위한 프롬프트 | |
max_connections | 기업 전용으로 Teleport를 통해 시작할 수 있는 동시 세션 수 제한 | 가장 낮은 값이 우선합니다. |
max_kubernetes_connections | 사용자당 최대 동시 Kubernetes 세션 수 정의 | |
record_session | 세션 녹화 모드 정의 | 가장 엄격한 값이 우선합니다. |
desktop_clipboard | 데스크탑 세션을 위한 클립보드 공유 허용 | 논리적 "AND", 즉 모든 역할이 클립보드 공유를 활성화해야 "예"로 평가됩니다 |
desktop_directory_sharing | 로컬 워크스테이션 디렉토리를 원격 데스크탑에 공유 허용 | 논리적 "AND", 즉 모든 역할이 디렉토리 공유를 활성화해야 "예"로 평가됩니다 |
pin_source_ip | SSH 인증서에 대한 소스 IP 핀을 활성화합니다. | 논리적 "OR", 즉 한 역할이라도 세션 종료를 요구하면 "예"로 평가됩니다 |
cert_extensions | SSH 인증서에 포함할 확장자를 지정합니다 | |
create_host_user_mode | 호스트에서 사용자가 자동으로 생성되도록 허용 | 논리적 "AND", 즉 서버와 일치하는 모든 역할이 호스트 사용자 생성을 지정할 경우 (off , keep , insecure-drop ), 모든 역할에 의해 지정된 옵션으로 평가됩니다. 일부 역할이 insecure-drop 또는 keep 를 지정하는 경우 keep 으로 평가됩니다. |
create_db_user_mode | 데이터베이스 사용자 자동 프로비저닝 허용. 옵션: off (데이터베이스 사용자 자동 프로비저닝 비활성화), keep (세션 종료 시 사용자를 비활성화하며 역할을 제거하고 잠급니다), 및 best_effort_drop (세션 종료 시 사용자를 삭제하려고 시도하되 실패 시 비활성화로 되돌립니다). | 논리적 "OR", 즉 어떤 역할이라도 데이터베이스 사용자 자동 프로비저닝을 허용하면 허용됩니다 |
사전 설정된 역할
Teleport는 여러 개의 사전 설정된 역할을 제공합니다:
역할 | 설명 | 엔터프라이즈 전용 |
---|---|---|
access | 클러스터 리소스에 대한 액세스를 허용합니다. | |
editor | 클러스터 구성 설정을 편집할 수 있습니다. | |
auditor | 클러스터 이벤트, 감사 로그를 읽고 세션 기록을 재생할 수 있습니다. | |
requester | 사용자가 접근 요청을 생성할 수 있도록 허용합니다. | ✔ |
reviewer | 접근 요청을 검토할 수 있도록 허용합니다. | ✔ |
group-access | 모든 사용자 그룹에 대한 액세스를 허용합니다. | ✔ |
device-admin | 신뢰할 수 있는 장치를 관리하는 데 사용됩니다. | ✔ |
device-enroll | 사용자에게 장치 등록 권한을 부여하는 데 사용됩니다. | ✔ |
require-trusted-device | 리소스에 대한 접근을 위해 신뢰할 수 있는 장치가 필요합니다. | ✔ |
terraform-provider | Teleport Terraform 제공자가 지원하는 모든 Teleport 리소스를 구성할 수 있도록 허용합니다. | ✔ |
역할 버전
현재 지원되는 역할 버전은 v3
, v4
, v5
, v6
, 및 v7
입니다.
v4
및 그 이상의 역할은 v3
와 완전히 호환됩니다. 유일한 차이점은 명시적으로 설정되지 않은 경우 역할에 적용될 기본 값입니다. 또한, v5
이상의 버전의 역할은 Moderated Sessions 를 사용해야 합니다.
라벨 | v3 기본값 | v4 및 그 이상 기본값 |
---|---|---|
node_labels | [{"*": "*"}] 역할에 로그인 항목이 있는 경우, 그렇지 않으면 [] | [] |
app_labels | [{"*": "*"}] | [] |
kubernetes_labels | [{"*": "*"}] | [] |
db_labels | [{"*": "*"}] | [] |
버전 v6
는 Kubernetes 리소스에 대한 세분화된 제어를 허용하는 새로운 필드 kubernetes_resources
를 도입했습니다. 자세한 내용은 Kubernetes RBAC 를 참조하세요.
버전 | kubernetes_resources |
---|---|
v3 , v4 및 v5 기본값 | [{"kind":"pod", "name":"*", "namespace":"*", "verbs": ["*"]}] |
v6 기본값 | [] |
v7 기본값 | [{"kind":"*", "name":"*", "namespace":"*", "verbs": ["*"]}] |
인프라 리소스에 대한 RBAC
Teleport 역할은 사용자가 액세스할 수 있는 리소스(예: 애플리케이션, 서버 및 데이터베이스)를 정의합니다. 이는 역할 정의에 있는 허용/거부 라벨을 구성하고 리소스에 라벨을 부여하는 방식으로 작동합니다.
다음 사용 사례를 고려하십시오:
인프라는 environment=production
및 environment=staging
과 같은 라벨을 사용하여 스테이징/프로덕션 환경으로 나뉩니다.
하나의 환경에만 액세스할 수 있는 역할을 생성할 수 있습니다.
예를 들어, 라벨 environment=staging
에 대한 허용 규칙이 있는 인턴 역할을 만든다고 가정해 보겠습니다.
예시
아래 역할은 "env=stage" 라벨이 있는 모든 노드에 대한 액세스를 허용하지만, "workload=database" 또는 "workload=backup" 라벨이 있는 노드는 제외합니다.
기타 노드에 대한 액세스는 거부됩니다.
kind: role
version: v5
metadata:
name: example-role
spec:
allow:
node_labels:
"env": "stage"
deny:
node_labels:
# 여러 라벨은 "or" 작업으로 해석됩니다. 이 경우,
# Teleport는 'workload=database' 또는 'workload=backup' 라벨이 있는 노드에 대한 액세스를 거부합니다.
"workload": ["database", "backup"]
Teleport는 여러 라벨 항목을 논리적 "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
레이블 표현식은 Teleport 버전 13.1.1
부터 사용할 수 있습니다. Teleport
클러스터의 모든 구성 요소는 레이블 표현식을 사용하기 전에 버전 13.1.1
또는
그 이상으로 업그레이드되어야 합니다. 여기에는 Auth Service와 모든 Teleport
에이전트가 포함됩니다.
Teleport 역할은 다음과 같은 경우에 필요할 때 목적 표현식을 사용하여 리소스 레이블을 일치시키는 것도 지원합니다:
- OR 및 AND 연산자를 결합하는 논리
- 레이블 키에서 일치 수행
- 부정 일치 구현
다음 예제 역할은 env=staging
으로 레이블이 지정된 노드 또는 team=<team>
으로 레이블이 지정된 노드에 대한 액세스를 허용합니다. 여기서 <team>
은 사용자의 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.allow
및 spec.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
중 하나만 사용하는 것이 좋지만 두 가지를 모두 지정할 수 있습니다.
거부 규칙에 두 가지가 모두 있을 경우 일치는 탐욕적이며, 어떤 하나라도 일치하면 액세스가 거부됩니다.
허용 규칙에서는 일치가 탐욕적이지 않으며, 두 가지가 모두 설정되면 액세스를 허용하기 위해 둘 다 일치해야 합니다.
동적 Teleport 리소스를 위한 RBAC
RBAC는 팀이 Teleport 사용자에게 제공되는 리소스를 제한할 수 있도록 합니다. 예를 들어, 일반 사용자가 SSO (auth_connector
)를 수정하거나 새 역할(role
)을 만들고 편집하는 것을 원하지 않을 때 유용할 수 있습니다.
RBAC 리소스를 수정하기 위한 규칙은 두 부분으로 구성됩니다: 리소스 및 동사. 다음은 SSH sessions
리소스에 적용된 list
동사를 설명하는 allow
규칙의 예입니다. 이는 "이 역할의 사용자가 활성 SSH 세션 목록을 볼 수 있도록 허용"하는 것을 의미합니다.
allow:
- resources: [session]
verbs: [list]
이 규칙이 역할 정의의 deny
섹션에 선언되었다면 사용자가 활성 세션 목록을 가져오는 것을 금지하게 됩니다. 아래 예제 역할 구성의 allow
섹션에서 사용 가능한 모든 리소스와 동사를 확인할 수 있습니다.
다음은 일반적으로 사용되는 rules
를 설명하는 allow
섹션의 예입니다.
각 규칙에는 Teleport 리소스 목록과 사용자가 해당 리소스에서 실행할 수 있는 CRUD 작업이 포함됩니다:
allow:
rules:
# Teleport 서버 액세스 노드를 관리하기 위한 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]
# Auth 커넥터는 SSO 커넥터라고도 알려져 있습니다.
- resources:
- auth_connector
verbs: [list, create, read, update, delete]
# 세션: 세션 녹화에 대한 액세스를 제공합니다.
# 예를 들어 세션 읽기가 false인 경우 사용자는 녹화를 재생할 수 없습니다.
# "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]
토큰 리소스에 대한 액세스 허용
토큰 생성을 허용하는 역할을 구성하면, 해당 역할에 할당된 사용자는 Teleport 리소스의 모든 유형을 프로비저닝하기 위해 토큰을 생성할 수 있습니다.
예를 들어, 할당된 사용자가 서버를 등록할 수 있도록 다음과 같은 구성을 가진 역할을 생성할 수 있습니다:
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: {}
이러한 권한을 가진 사용자는 서버, 애플리케이션 또는 데이터베이스를 등록하기 위해 토큰을 생성하거나, 루트 클러스터와 새로운 Teleport Proxy 서비스 간의 신뢰 관계를 설정하거나, 새로운 리프 클러스터를 추가할 수 있습니다.
토큰 리소스는 특정 컨텍스트(예: 노드 또는 신뢰 클러스터)로 스코프하지 않기 때문에, 토큰 권한을 제공하는 역할은 관리 역할로 간주해야 합니다. 특히, 예기치 않은 클러스터의 구성이나 상태 변경을 방지하기 위해 token
리소스에서 create
및 update
권한을 부여하는 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:
# Teleport는 사용자 세션과 기본적으로 사용자가 참여할 수 있는 세션에 대한 세션 액세스를 허용합니다.
# 이를 통해 모든 세션을 볼 수 있습니다.
- resources: [session_tracker]
verbs: ["*"]
deny:
rules:
# ... 그리고 그 액세스를 거부 규칙으로 제한합니다.
# 거부 규칙은 허용 규칙보다 우선하므로, 결과적으로 사용자가 자신의 활성 세션만 볼 수 있도록 합니다.
- resources: [session_tracker]
verbs: [list, read, update, delete]
where: "!contains(session_tracker.participants, user.metadata.name)"
역할 템플릿
Teleport 역할 리소스의 특정 필드는 사용자의 액세스를 구성하기 위해 함수와 변수를 사용할 수 있도록 허용합니다. 필드에 사용할 수 있는 함수와 변수는 필드가 구성하는 액세스 제어에 따라 다릅니다.
인프라 리소스에 대한 액세스 템플릿 표현식
사용자가 Teleport에 의해 프록시된 인프라 리소스(예: 데이터베이스 또는 Kubernetes 클러스터)에 인증을 시도할 때, Teleport는 사용자의 역할에 따라 결정합니다:
- 사용자가 리소스에 연결할 수 있는 권한이 있는지 여부.
- 사용자가 인증할 때 어떤 주체를 수임할 수 있는지(예: Linux 서버 로그인 및 Kubernetes 그룹).
필드
다음 역할 필드는 사용자의 인프라 리소스에 대한 액세스를 제어합니다.
이 모든 필드는 Teleport 역할 리소스의 allow
및 deny
섹션 내에 있습니다.
Teleport에 등록된 리소스 레이블:
역할 필드 | Teleport 리소스 |
---|---|
app_labels | 어플리케이션 |
cluster_labels | 신뢰할 수 있는 클러스터 |
db_labels | 데이터베이스 |
db_service_labels | 데이터베이스 서비스 인스턴스 |
kubernetes_labels | Kubernetes 클러스터 |
node_labels | SSH 서버 |
windows_desktop_labels | Windows 데스크톱 |
사용자가 인프라 리소스에서 가질 수 있는 주체:
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
사용자가 가장할 수 있는 Teleport 주체:
impersonate.rules
impersonate.users
함수
인프라 리소스의 주체에 대한 액세스를 규제하는 역할 필드에서 다음 함수를 사용할 수 있습니다:
함수 | 설명 |
---|---|
{{email.local(variable)}} | 이메일 주소의 로컬 부분을 추출합니다. |
{{regexp.replace(variable, expression, replacement)}} | 변수 내에서 표현식의 모든 일치를 찾아 대체 값으로 바꿉니다. |
특성
인프라 리소스에 대한 액세스를 구성하는 필드의 경우, Teleport는 인증하는 사용자로부터 로컬 사용자 데이터베이스와 사용자의 외부 단일 로그온 공급자를 통해 다음 특성을 대체합니다.
변수 | 설명 |
---|---|
{{internal.aws_role_arns}} | 사용자에게 허용된 AWS 역할 ARNS 목록. |
{{internal.azure_identities}} | 사용자에게 사용 가능한 Teleport에 정의된 Azure ID 목록을 반환합니다. Azure ID는 특정 사용자에 대해 설정하거나 역할에 정의할 수 있습니다. |
{{internal.db_names}} | 사용자에게 허용된 데이터베이스 이름 목록. |
{{internal.db_roles}} | 사용자에게 허용된 데이터베이스 역할 목록. |
{{internal.db_users}} | 사용자에게 허용된 데이터베이스 사용자 목록. |
{{internal.gcp_service_accounts}} | 사용자에게 허용된 GCP 서비스 계정 목록. |
{{internal.jwt}} | 앱 액세스에 사용되는 JWT 헤더. |
{{internal.kubernetes_groups}} | 사용자에게 허용된 Kubernetes 그룹 목록. |
{{internal.kubernetes_users}} | 사용자에게 허용된 Kubernetes 사용자 목록. |
{{internal.logins}} | Teleport의 로컬 사용자 데이터베이스와 루트 클러스터의 로그인에서 저장된 값으로 대체됩니다. 로컬 사용자에 대해 Teleport는 tctl users add [user] <allowed logins> 명령에서 사용되는 "허용된 로그인" 매개변수로 이를 대체합니다. 역할이 신뢰할 수 있는 클러스터의 리프 클러스터 내에 있는 경우, Teleport는 사용자가 로컬 사용자이든 SSO 공급자에서 왔든 루트 클러스터의 로그인을 대체합니다. 예를 들어 사용자가 루트 클러스터에서 ubuntu 로그인과 함께 있을 경우, 이 변수에 따라 리프 클러스터에서 ubuntu 로 대체됩니다. |
{{internal.windows_logins}} | 사용자에게 허용된 Windows 로그인 목록. |
{{external.xyz}} | 외부 SSO 공급자에서 가져온 값으로 대체됩니다. SAML을 사용하는 경우 "xyz" assertion 값으로 확장됩니다. OIDC의 경우 이 변수는 "xyz" claim의 값으로 확장됩니다. Teleport 역할에서 external 변수를 참조하는 방법에 대한 추가 정보는 다음 섹션을 참조하십시오. |
Teleport 역할에서 내부 특성 참조하기
internal
특성 네임스페이스는 위 표에 포함된 정확한 내부 특성 이름만 포함합니다.
로컬 Teleport 사용자에 대해 이러한 특성은 사용자 리소스의
spec.traits
필드에 설정할 수 있습니다.
이러한 특성 이름은 IdP에서 제공하는 속성 또는 클레임에 포함되어 있는 경우 SSO 사용자에게도 설정할 수 있습니다.
내부 특성은 사용자 특성에 따라 리소스에 대한 액세스를 허용하기 위해
preset roles access
및 require-trusted-device
에서 참조됩니다.
外부 특성은 사전 설정된 역할에서 절대 참조되지 않습니다 (수동으로 해당 사전 설정된 역할을 편집하지 않는 한).
역할에서 내부 특성을 참조하려면 다음 형식을 사용할 수 있습니다:
logins:
- "{{internal.logins}}"
Warning
하위 클러스터와 루트 클러스터에서 확장될 때 일부 내부 특성이 다를 수 있으므로
하위 호환성을 위해 주의하십시오. 하위 클러스터에서는 logins
,
kubernetes_groups
, kubernetes_users
, db_names
, db_users
, 및
aws_role_arns
특성이 모두 사용자가 Teleport에 로그인할 때 사용자 인증서에
인코딩된 전체 값 집합으로 설정됩니다. 예를 들어, 하위 클러스터에 액세스할 때
internal.logins
특성은 사용자에게 허용된 SSH 로그인의 전체 목록으로
설정되며, 이는 루트 클러스터에서 사용자의 internal.logins
특성에서 가져온
값과 루트 클러스터에서 사용자가 보유한 역할의 spec.allow.logins
필드에만
포함된 로그인을 포함할 수 있습니다.
Teleport 역할에서 외부 특성 참조하기
로컬 Teleport 사용자에 대해 external
특성 네임스페이스에는
사용자 리소스의 spec.traits
필드에 있는 모든 값이 포함됩니다.
여기에는 사용자 정의 특성 이름과 위에 나열된 internal
특성과 일치하는 이름이 포함됩니다.
예를 들어, {{internal.logins}}
및 {{external.logins}}
는 모두
logins
특성을 참조하는 유효한 방법이지만, groups
라는 사용자 정의 특성은
{{external.groups}}
로만 참조할 수 있습니다.
사용자가 단일 사인온 신원 공급자(IdP)를 통해 Teleport에 인증하면
Teleport는 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"]}}
Teleport는 위의 템플릿 변수를 SAML 속성 또는 OIDC 클레임의 값으로 확장합니다.
특성이 문자로 시작하고 문자, 숫자 및 밑줄만 포함하면 점 표기법을 사용하여 외부 특성을 지정할 수 있습니다. 그렇지 않으면 대괄호 표기법을 사용하여 특성을 지정해야 합니다.
Azure AD 또는 ADFS를 IdP로 사용하는 경우 대괄호 표기법을 사용해야 하며,
이 IdP는 다음과 같은 URL에 속성 키를 할당합니다:
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
신원 공급자를 통해 사용할 수 있는 외부 특성의 일반적인 예는 다음과 같습니다:
{{external.logins}}
{{external.username}}
{{external.env}}
Teleport는 external
변수를 문자열 또는 문자열 목록으로만 확장할 수 있습니다.
OIDC 기반 SSO 솔루션을 사용하는 경우 지원되는 데이터 유형을 가진 값을 포함하는 클레임이
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 스타일 정규 표현식을 모두 지원합니다. 표현식이 ^
문자로 시작하고 $
문자로 끝나면, Teleport는 이를 정규 표현식으로 평가합니다. 그렇지 않으면 와일드카드 표현식으로 평가합니다. 와일드카드는 0개 이상의 문자 시퀀스와 일치합니다.
변수
Teleport는 위 필드의 값에 대해 변수 확장을 수행하지 않습니다.
필터 필드
다음은 이 가이드 내에서 where
및 filter
조건에 사용되는 필드에 대한 설명입니다:
필드 | 설명 |
---|---|
user.spec.roles | 사용자에게 할당된 역할 목록 |
session.participants | 세션 녹화에서의 참가자 목록 |
session_tracker.participants | 세션의 참가자 목록 |
user.metadata.name | 사용자의 이름 |
보다 심층적인 설명은 프레디케이트 언어 가이드를 참조하세요.