인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!
Teleport 역할 템플릿
조직이 성장함에 따라 인프라 팀은 사람들이 합류하고 떠나고 새로운 팀을 형성할 때마다 수동 구성을 요구하지 않는 액세스 제어 정책을 정의하는 방법을 찾아야 합니다.
다음은 이러한 정책의 일반적인 예입니다:
- 모든 SSO 사용자가 자신의 이메일에서 생성된 SSH 로그인 제공.
- 각 팀 구성원을 팀의 Kubernetes 그룹에 할당.
- 개발 팀은 데이터베이스의 읽기 전용 복제본으로 제한.
이제 Teleport의 역할 템플릿이 이러한 정책과 기타 정책을 설명하는 방법을 알아보겠습니다.
전제 조건
-
실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
-
tctl
관리자 도구와tsh
클라이언트 도구.tctl
및tsh
다운로드 방법에 대한 지침은 설치를 방문하십시오.
- 연결이 가능한지 확인하기 위해
tsh login
으로 로그인한 다음, 현재 자격 증명을 사용하여tctl
명령어를 실행할 수 있는지 확인하십시오. 예를 들어:클러스터에 연결할 수 있고tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 17.0.0-dev
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status
명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속tctl
명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로tctl
명령어를 실행할 수도 있습니다.
로컬 사용자
Alice와 Bob이라는 두 사용자가 있다고 가정해 보겠습니다. 우리는 다음과 같은 액세스 정책을 설정하고자 합니다:
- Alice는 SSH 사용자
admin
및 Kubernetes 그룹edit
로 로그인할 수 있습니다. - Bob은
ubuntu
및 Kubernetes 그룹view
로 로그인할 수 있습니다.
우리는 roles.yaml
파일에 각 사용자에 대한 두 개의 역할을 생성할 수 있습니다:
kind: role
version: v7
metadata:
name: alice
spec:
allow:
logins: ["admin"]
kubernetes_groups: ["edit"]
node_labels:
"*": "*"
kubernetes_labels:
"*": "*"
kubernetes_resources:
- kind: "*"
namespace: "*"
name: "*"
verbs: ["*"]
---
kind: role
version: v7
metadata:
name: bob
spec:
allow:
logins: ["ubuntu"]
kubernetes_groups: ["view"]
node_labels:
"*": "*"
kubernetes_labels:
"*": "*"
kubernetes_resources:
- kind: "*"
namespace: "*"
name: "*"
verbs: ["*"]
역할을 생성하고 Alice와 Bob을 로컬 사용자로 초대할 수 있습니다:
tctl create -f roles.yamltctl users add alice --roles=alicetctl users add bob --roles=bob
각 사용자마다 하나의 역할을 갖는 것은 잘 확장되지 않을 것입니다. 역할이 매우 유사하기 때문에 각 사용자에게 변수를 할당하고 하나의 역할 템플릿만 사용하도록 할 수 있습니다.
devs.yaml
이라는 역할 템플릿을 만들어 보겠습니다:
kind: role
version: v7
metadata:
name: devs
spec:
allow:
logins: ["{{internal.logins}}"]
kubernetes_groups: ["{{internal.kubernetes_groups}}"]
node_labels:
"*": "*"
kubernetes_labels:
"*": "*"
kubernetes_resources:
- kind: "*"
namespace: "*"
name: "*"
verbs: ["*"]
역할이 템플릿 변수를 사용하기 시작하면 모든 역할은 템플릿이 됩니다.
역할과 마찬가지로 역할 템플릿은 유효한 YAML이며 구조와 유형을 모두 검증합니다.
역할 템플릿 devs
는 로컬 사용자의 특성 logins
및 kubernetes_groups
를 참조하기 위해 internal
표기를 사용하고 있습니다. internal
표기는 제한된 수의 미리 정의된 특성만 지원합니다. 로컬 사용자와 함께 사용자 정의 특성을 사용하는 경우 external.<trait-name>
구문을 사용하십시오.
tctl
을 사용하여 역할 템플릿을 생성하십시오:
tctl create -f devs.yaml
마지막 단계는 Alice와 Bob의 사용자에 특성을 업데이트하는 것입니다. traits.yaml
이라는 파일에 사용자 리소스의 예는 다음과 같습니다:
kind: user
version: v2
metadata:
name: alice
spec:
roles: ["devs"]
traits:
logins: ["admin"]
kubernetes_groups: ["edit"]
---
kind: user
version: v2
metadata:
name: bob
spec:
roles: ["devs"]
traits:
logins: ["ubuntu"]
kubernetes_groups: ["view"]
두 사용자의 항목을 tctl create -f
명령으로 업데이트하십시오:
tctl create -f traits.yaml사용자 "alice"가 업데이트되었습니다.
Alice가 로그인하면 그녀는 새로운 역할로 SSH 및 X.509 인증서를 받게 됩니다. SSH 로그인 및 Kubernetes 그룹도 설정됩니다:
tsh login --proxy=teleport.example.com --user=alice> 프로필 URL: https://teleport.example.com:443
로그인한 사용자: alice
클러스터: teleport.example.com
역할: devs*
로그인: admin
Kubernetes: 사용 가능
Kubernetes 그룹: edit
유효 기간: 2021-03-26 07:13:57 -0700 PDT [유효 기간 12h0m0s]
확장: permit-port-forwarding, permit-pty
tsh login --proxy=mytenant.teleport.sh --user=alice> 프로필 URL: https://mytenant.teleport.sh:443
로그인한 사용자: alice
클러스터: mytenant.teleport.sh
역할: devs*
로그인: admin
Kubernetes: 사용 가능
Kubernetes 그룹: edit
유효 기간: 2021-03-26 07:13:57 -0700 PDT [유효 기간 12h0m0s]
확장: permit-port-forwarding, permit-pty
SSO 사용자
ID 공급자 관리자는 사용자에게 그룹 구성원 자격 또는 접근 권한과 같은 메타데이터를 지정할 수 있습니다. 관리자는 Teleport와 공유할 메타데이터를 구성합니다. Teleport는 OIDC 클레임 또는 SAML 속성으로 사용자 메타데이터 키와 값을 수신합니다 단일 로그인 리디렉션 흐름:
# 앨리스의 이메일은 alice@example.com 입니다. 이메일은 표준 OIDC 클레임입니다.
email: "alice@example.com"
# 앨리스는 admins 및 devs 그룹의 구성원입니다.
groups: ["admins", "devs"]
# 그녀는 prod 및 staging 환경에 접근할 수 있습니다.
env: ["prod", "staging"]
ID 공급자에 의해 설정된 외부 속성 logins
를 기대하는 sso-users
라는 역할 템플릿을 만들어 보겠습니다. 이 역할을 sso-users.yaml
로 저장하세요:
kind: role
version: v7
metadata:
name: sso-users
spec:
allow:
logins: ["{{external.logins}}"]
node_labels:
"*": "*"
kubernetes_labels:
"*": "*"
kubernetes_resources:
- kind: "*"
namespace: "*"
name: "*"
verbs: ["*"]
가입된 조직 octocats
의 팀 cyber
의 모든 구성원을 역할 sso-users
에 매핑하는 github.yaml
이라는 GitHub 커넥터를 만듭니다:
kind: github
version: v3
metadata:
name: github
spec:
# GitHub OAuth 앱의 클라이언트 ID
client_id: client-id
# GitHub OAuth 앱의 클라이언트 비밀
client_secret: secret-data-here
# 웹 UI 로그인 화면에 표시될 커넥터 표시 이름
display: GitHub
# 성공적인 인증 후 호출되는 콜백 URL
redirect_url: https://teleport.example.com/v1/webapi/github/callback
# 데이터에 대한 Teleport 역할과의 조직/팀 구성원 매핑
teams_to_roles:
- organization: octocats # GitHub 조직 이름
team: cyber # 해당 조직 내 GitHub 팀 이름
# 매핑할 역할 이름
roles:
- sso-users
tctl
을 사용하여 이 커넥터를 생성합니다:
tctl create -f github.yaml
Bob이 SSO를 사용하여 로그인하면, 그는 sso-users
역할 템플릿을 사용하여 생성된 새로운 역할과 SSH 로그인을 가진 SSH 및 X.509 인증서를 받을 것입니다:
tsh login --proxy=teleport.example.com --auth=github> 프로필 URL: https://teleport.example.com:443
로그인한 사용자: bob
클러스터: teleport.example.com
역할: sso-users*
로그인: bob
Kubernetes: 활성화됨
Kubernetes 그룹: edit
유효 기간: 2021-03-26 07:13:57 -0700 PDT [12시간 유효]
확장 기능: permit-port-forwarding, permit-pty
tsh login --proxy=mytenant.teleport.sh --auth=github> 프로필 URL: https://mytenant.teleport.sh:443
로그인한 사용자: bob
클러스터: mytenant.teleport.sh
역할: sso-users*
로그인: bob
Kubernetes: 활성화됨
Kubernetes 그룹: edit
유효 기간: 2021-03-26 07:13:57 -0700 PDT [12시간 유효]
확장 기능: permit-port-forwarding, permit-pty
보간 규칙
관리자는 SSO 중에 어떤 속성을 ID 공급자가 반환하고 Teleport에 제공할지를 구성할 수 있습니다. 몇 가지 시나리오를 검토하고 Teleport가 변수를 어떻게 보간하는지 살펴보겠습니다.
앨리스의 사용자 항목에 대한 속성 목록으로 돌아가 봅시다:
# 앨리스의 이메일은 alice@example.com입니다. 이메일은 표준 OIDC 클레임입니다.
email: "alice@example.com"
# 앨리스는 admins 및 devs 그룹의 일원입니다.
groups: ["admins", "devs"]
# 그녀는 프로덕션 및 스테이징 환경에 접근할 수 있습니다.
env: ["prod", "staging"]
이 변수가 역할 템플릿 interpolation
와 어떻게 사용되는지 살펴보겠습니다:
kind: role
version: v7
metadata:
name: interpolation
spec:
allow:
# 역할 템플릿 필드는 하드코딩된 값과 변수를 혼합할 수 있습니다.
logins: ["{{external.logins}}", "admin"]
# 역할은 문자열 값의 보간을 지원합니다.
kubernetes_users: ["IAM#{{external.email}};"]
# 리스트는 리스트로 확장됩니다.
kubernetes_groups: ["{{external.groups}}"]
# 함수는 변수를 변환합니다.
database_users: ["{{email.local(external.email)}}"]
db_labels:
"env": '{{regexp.replace(external.env, "^(staging)$", "$1")}}'
# 레이블은 템플릿과 하드코딩된 값을 혼합할 수 있습니다.
node_labels:
"env": "{{external.env}}"
"region": "us-west-2"
kubernetes_labels:
"*": "*"
kubernetes_resources:
- kind: "*"
namespace: "*"
name: "*"
verbs: ["*"]
앨리스의 SSO 사용자 속성으로 보간한 후, 역할 템플릿은 다음과 같은 역할로 동작하게 됩니다:
kind: role
version: v7
metadata:
name: interpolation
spec:
allow:
# 변수 external.logins는 공급자에 의해 전송되지 않으며, 빈 값으로 렌더링되어 하드코딩된 admin 값만 남습니다.
logins: ["admin"]
# 변수 external.email은 문자열에 확장됩니다.
kubernetes_users: ["IAM#alice@example.com;"]
# 변수 external.groups는 리스트로 교체됩니다.
kubernetes_groups: ["devs", "admins"]
# 함수 email.local은 external.email 속성의 로컬 부분을 가져옵니다.
database_users: ["alice"]
# 함수 regexp.replace는 일치하는 값만 변환하고 필터링합니다.
db_labels:
"env": "staging"
# 노드 레이블은 변수에서 'env'가 대체되고 'region'은 하드코딩됩니다.
node_labels:
"env": ["prod", "staging"]
"region": "us-west-2"
kubernetes_labels:
"*": "*"
kubernetes_resources:
- kind: "*"
namespace: "*"
name: "*"
verbs: ["*"]
사용 가능한 보간 함수는 다음과 같습니다:
Function | Description |
---|---|
email.local(variable) | 이메일 주소의 로컬 부분을 추출합니다. email.local(alice@example.com) 은 alice 로 평가됩니다. |
regexp.replace(variable, expression, replacement) | expression 의 모든 일치를 찾아 replacement 로 교체합니다. 이는 확장을 지원합니다. 예: regexp.replace(external.email, "^(.*)@example.com$", "$1") . 표현식과 일치하지 않는 값은 필터링됩니다. $N 은 N번째 캡처 그룹을 참조하는 데 사용되며, $1 부터 시작합니다. |
액세스 요청에서의 템플릿화
액세스 및 검토 요청 사양은 로그인, 라벨 등과 같은 동일한 보간 시스템을 사용하지 않습니다. 대신, request
및 review
규칙의 claims_to_roles
절을 사용하여 하나 이상의 패턴을 지정할 수 있습니다.
예를 들어, 다음과 같은 규칙 템플릿이 주어졌을 때:
kind: role
version: v3
metadata:
name: product-admin
spec:
allow:
request:
# `roles` 는 `product-admin` 역할을 가진 사용자가
# 임시 액세스를 요청할 수 있는 역할의 정적 목록입니다.
roles: [access]
claims_to_roles:
- claim: "projects"
value: "^product-(.*)$" # 'product-'로 시작하는 모든 그룹 이름과 일치합니다.
roles: ["$1-admin"] # 값 캡처에서 역할 이름을 생성합니다.
예를 들어, 우리는 앨리스에게 product-admin
역할을 부여하고 projects
특성에 몇 개의 항목을 추가할 수 있습니다:
kind: user
version: v2
metadata:
name: alice
spec:
roles: ["dev", "product-admin"]
traits:
projects: ["internal-tooling", "product-alpha", "product-beta"]
이 경우, 앨리스는 정적 역할 목록에서 access
에 대한 액세스를 요청하고 claims_to_roles
매핑에서 alpha-admin
및 beta-admin
에 대한 액세스를 요청할 수 있습니다.
검토 요청에도 동일한 구문이 적용됩니다.