Teleport에서는 모든 로컬, SSO 또는 로봇 사용자에게 여러 개의 역할을 할당할 수 있습니다.
역할은 데이터베이스, SSH 서버, Kubernetes 클러스터, Windows 데스크톱 및 웹 앱에 대한 액세스를 관리합니다.
우리는 로컬 사용자와 사전 설정된 역할부터 시작하여 SSO 사용자에게 역할을 할당하고
자신의 역할을 만드는 것으로 마무리하겠습니다.
전제 조건
-
실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.
-
tctl
관리 도구와tsh
클라이언트 도구.tctl
과tsh
다운로드에 대한 지침은 설치를 방문하세요.
- 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면,
tsh login
으로 로그인한 다음 현재 자격 증명을 사용하여tctl
명령어를 실행할 수 있는지 확인하십시오. 예를 들어:클러스터에 연결하고tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 16.2.0
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status
명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속tctl
명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로tctl
명령어를 실행할 수도 있습니다.
프로덕션에서 Teleport를 실행할 때 보안 사고를 피하기 위해 다음 모범 사례를 준수해야 합니다:
- 필요한 경우가 아니면 프로덕션 환경에서
sudo
사용을 피하세요. - 새로운 비루트 사용자 계정을 생성하고 Teleport 실험을 위해 테스트 인스턴스를 사용하세요.
- 필요하지 않는 한 비루트 사용자로서 Teleport의 서비스를 실행하세요. SSH 서비스만 루트 접근을 필요로 합니다. Teleport가
1024
보다 작은 포트(예:443
)에서 수신 대기하도록 하려면 루트 권한(또는CAP_NET_BIND_SERVICE
권한)이 필요합니다. - 최소 권한 원칙을 따르세요. 더 제한적인 역할로도 충분할 때 사용자의 권한을 허용하는 역할을 부여하지 마세요.
예를 들어, 사용자가 모든 클러스터 리소스에 액세스하고 편집할 수 있는 내장된
access,editor
역할을 부여하지 마세요. 대신 각 사용자에게 필요한 최소 권한을 가진 역할을 정의하고 액세스 요청을 구성하여 일시적으로 권한을 상승시켜주세요. - Teleport 리소스를 등록할 때(예: 새로운 데이터베이스나 응용 프로그램) 초대 토큰을 파일에 저장해야 합니다.
명령행에 토큰을 직접 입력하면 악의적인 사용자가 손상된 시스템에서
history
명령을 실행하여 이를 볼 수 있습니다.
이러한 관행이 문서에서 사용되는 예제에 반드시 반영되지 않는 점에 유의해야 합니다. 문서의 예제는 주로 시연 및 개발 환경을 위한 것입니다.
1단계/3. 사전 설정된 역할을 가진 로컬 사용자 추가하기
Teleport는 여러 개의 사전 설정된 역할을 제공합니다:
역할 | 설명 |
---|---|
access | 클러스터 리소스에 대한 접근을 허용합니다. |
editor | 클러스터 구성 설정을 편집할 수 있습니다. |
auditor | 클러스터 이벤트, 감사 로그를 읽고 세션 기록을 재생할 수 있습니다. |
requester | 사용자에게 접근 요청을 생성할 수 있는 엔터프라이즈 전용 역할입니다. |
reviewer | 접근 요청을 검토할 수 있는 엔터프라이즈 전용 역할입니다. |
group-access | 모든 사용자 그룹에 대한 접근을 허용합니다. |
device-admin | 신뢰할 수 있는 장치를 관리하는 데 사용됩니다. |
device-enroll | 사용자에게 장치 등록 권한을 부여하는 데 사용됩니다. |
require-trusted-device | 리소스에 대한 접근을 위해 신뢰할 수 있는 장치가 필요합니다. |
terraform-provider | Teleport Terraform 공급자가 모든 지원되는 Teleport 리소스를 구성할 수 있도록 허용합니다. |
로컬 사용자 Alice를 클러스터 editor
로 초대합니다:
tctl users add alice --roles=editor
로컬 사용자 Alice를 클러스터 editor
및 reviewer
로 초대합니다:
tctl users add alice --roles=editor,reviewer
Alice가 가입하면 클러스터 구성을 수정할 수 있습니다. 사용자의 역할 목록을
tctl users ls
를 사용하여 확인할 수 있습니다.
tctl users ls사용자 역할
-------------------- --------------
alice editor
tctl users ls사용자 역할
-------------------- --------------
alice editor, reviewer
사용자의 역할을 업데이트 하려면 tctl users update
명령어를 사용합니다:
Alice가 다시 로그인을 하면 감사 로그를 볼 수 있습니다
tctl users update alice --set-roles=editor,auditor
Alice가 다시 로그인을 하면 감사 로그를 볼 수 있습니다
tctl users update alice --set-roles=editor,reviewer,auditor
Alice가 두 개 이상의 역할을 가지므로, 그 역할의 권한은 합집합을 형성합니다. 그녀는
동시에 시스템 관리자와 감사자로 활동할 수 있습니다.
2단계/3. SSO 사용자를 역할에 매핑하기
다음으로, SSO 솔루션 내의 사용자를 Teleport 역할과 매핑하는 인증 커넥터
설정 지침을 따르세요.
Teleport 엔터프라이즈
Teleport가 통합할 수 있는 SAML 또는 OIDC 애플리케이션을 생성한 다음,
애플리케이션 내의 사용자를 Teleport 역할에 매핑하는 인증 커넥터를 생성합니다.
다음의 SAML Okta 가이드를 참고하여
SAML 애플리케이션을 생성하세요.
아래 파일을 okta.yaml
로 저장하고 acs
필드를 업데이트하세요.
Okta 그룹 okta-admin
의 모든 구성원은 내장 역할 admin
을 가집니다.
kind: saml
version: v2
metadata:
name: okta
spec:
acs: https://tele.example.com/v1/webapi/saml/acs
attributes_to_roles:
- {name: "groups", value: "okta-admin", roles: ["access"]}
entity_descriptor: |
<?xml !!! XML 설명자의 모든 줄이 4칸으로 들여쓰기 해야 합니다.
그렇지 않으면 작동하지 않습니다.
saml
리소스를 생성합니다:
tctl create okta.yaml
다음의 OIDC 가이드를 따라
OIDC 애플리케이션을 생성하세요.
아래 YAML을 oidc.yaml
이라는 파일로 복사하고, OIDC 애플리케이션의 세부 정보로
편집합니다.
(!examples/resources/oidc-connector.yaml!)
oidc
리소스를 생성합니다:
tctl create okta.yaml
Teleport 커뮤니티 에디션
아래 파일을 github.yaml
로 저장하고 필드를 업데이트하세요.
GitHub OAuth 2.0 커넥터
앱을 설정해야 합니다. GitHub 조직 octocats
에 속하고 팀 admin
에 소속된 모든
구성원이 내장 역할 access
를 가질 수 있습니다.
kind: github
version: v3
metadata:
# `tsh --auth=github login`과 함께 사용할 커넥터 이름
name: github
spec:
# GitHub OAuth 앱의 클라이언트 ID
client_id: client-id
# GitHub OAuth 앱의 클라이언트 비밀번호
client_secret: client-secret
# UI 로그인 화면에 표시될 이름
display: GitHub
# tele.example.com을 귀하의 도메인명으로 변경하세요
redirect_url: https://tele.example.com:443/v1/webapi/github/callback
# GitHub 팀을 Teleport 역할에 매핑합니다
teams_to_roles:
- organization: octocats # GitHub 조직 이름
team: admin # 해당 조직의 GitHub 팀 이름
# GitHub 관리자 팀을 Teleport의 "access" 역할에 매핑합니다
roles: ["access"]
github
리소스를 생성합니다:
tctl create github.yaml
3단계/3. 사용자 정의 역할 만들기
인턴을 위한 사용자 정의 역할을 생성해 보겠습니다. 인턴은 readonly
사용자로서
테스트 또는 스테이징 SSH 서버에 액세스할 수 있습니다. 우리는 그들이 일부 모니터링
웹 애플리케이션과 개발 Kubernetes 클러스터를 볼 수 있도록 허용합니다.
이 역할을 interns.yaml
로 저장하십시오:
kind: role
version: v7
metadata:
name: interns
spec:
allow:
# Logins는 SSH 로그인 주체를 구성합니다
logins: ['readonly']
# 이 역할을 가진 사용자를 내장 Kubernetes 그룹 "view"로 할당합니다
kubernetes_groups: ["view"]
# "staging" 또는 "test"로 라벨된 SSH 노드, Kubernetes 클러스터, 앱 또는 데이터베이스
# 에 액세스를 허용합니다
node_labels:
'env': ['staging', 'test']
kubernetes_labels:
'env': 'dev'
kubernetes_resources:
- kind: *
namespace: "*"
name: "*"
verbs: ["*"]
app_labels:
'type': ['monitoring']
# 금지 규칙은 항상 허용 규칙을 무시합니다.
deny:
# 모든 사용자에게 아무 노드, 데이터베이스, 앱 또는 Kubernetes 클러스터에 대한 액세스를 금지합니다.
node_labels:
'env': 'prod'
kubernetes_labels:
'env': 'prod'
kubernetes_resources:
- kind: "namespace"
name: "prod"
db_labels:
'env': 'prod'
app_labels:
'env': 'prod'
tctl create -f
명령어를 사용하여 역할을 생성합니다:
tctl create -f /tmp/interns.yaml시스템 내의 모든 역할 목록을 가져옵니다
tctl get roles --format text