조직이 성장함에 따라 인프라 팀은 사람들이 팀에 합류하거나, 떠나거나, 새로운 팀을 구성할 때마다 수동 구성이 필요하지 않은 접근 제어 정책을 정의하는 방법을 찾아야 합니다.

다음은 이러한 정책의 일반적인 예입니다:

• 모든 싱글 사인온 사용자에게 이메일로 생성된 SSH 로그인을 부여합니다.
• 각 팀원을 해당 팀의 Kubernetes 그룹에 할당합니다.
• 개발팀의 데이터베이스 접근을 읽기 전용 복제본으로 제한합니다.

Teleport의 역할 템플릿이 이러한 정책과 다른 정책들을 어떻게 설명하는지 살펴보겠습니다.

사전 요구 사항#

• 실행 중인 Teleport 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.

• tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Teleport 클러스터의 버전을 확인합니다. tctl and tsh clients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의 /v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다. teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:

     $ TELEPORT_DOMAIN=teleport.example.com:443
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     

  2. 사용 중인 플랫폼에 대한 지침에 따라 tctl and tsh clients를 설치합니다:

Mac

     `tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
 
     

       Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
       Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
       보장할 수 없습니다.
     

Windows - Powershell

     ```code
     $ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
     # Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     # NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     # Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```
 
   

 
   

Linux

     Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다.  RPM/DEB
     패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
     [설치 페이지](../installation/installation.mdx)를 참조하세요.
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     # Teleport binaries have been copied to /usr/local/bin
     ```
   

 

Teleport cluster에 연결할 수 있는지 확인하려면 tsh login으로 로그인한 다음, 현재 자격 증명으로 tctl 명령을 실행할 수 있는지 확인합니다.

예를 들어, teleport.example.com에 cluster 내 Teleport Proxy Service의 도메인 이름을, email@example.com에 Teleport 사용자 이름을 지정하여 다음 명령을 실행합니다:

$ tsh login --proxy=teleport.example.com --user=email@example.com
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

cluster에 연결하여 tctl status 명령을 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 이후의 tctl 명령을 실행할 수 있습니다. 자체 Teleport cluster를 호스팅하는 경우, 전체 권한을 얻기 위해 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.yaml
$ tctl users add alice --roles=alice
$ tctl users add bob --roles=bob

사용자별로 하나의 역할을 갖는 것은 확장성이 좋지 않습니다. 역할이 매우 유사하기 때문에 각 사용자에게 변수를 할당하고, Alice와 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는 internal 표기법을 사용하여 로컬 사용자의 속성인 logins와 kubernetes_groups를 참조합니다. 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
# user "alice" has been updated

Alice가 로그인하면 새 역할로 SSH 및 X.509 인증서를 받게 됩니다. SSH 로그인과 Kubernetes 그룹도 설정됩니다:

$ tsh login --proxy=teleport.example.com --user=alice

# > Profile URL:        https://teleport.example.com:443
#  Logged in as:       alice
#  Cluster:            teleport.example.com
#  Roles:              devs*
#  Logins:             admin
#  Kubernetes:         enabled
#  Kubernetes groups:  edit
#  Valid until:        2021-03-26 07:13:57 -0700 PDT [valid for 12h0m0s]
#  Extensions:         permit-port-forwarding, permit-pty

$ tsh login --proxy=mytenant.teleport.sh --user=alice

# > Profile URL:        https://mytenant.teleport.sh:443
#  Logged in as:       alice
#  Cluster:            mytenant.teleport.sh
#  Roles:              devs*
#  Logins:             admin
#  Kubernetes:         enabled
#  Kubernetes groups:  edit
#  Valid until:        2021-03-26 07:13:57 -0700 PDT [valid for 12h0m0s]
#  Extensions:         permit-port-forwarding, permit-pty

SSO 사용자#

아이덴티티 프로바이더 관리자는 사용자에게 그룹 멤버십이나 접근 권한과 같은 메타데이터를 할당할 수 있습니다. 관리자는 어떤 메타데이터가 Teleport와 공유되는지 구성합니다. Teleport는 싱글 사인온 리다이렉트 플로우 중에 OIDC 클레임 또는 SAML 속성으로 사용자 메타데이터 키와 값을 받습니다:

# Alice의 이메일은 alice@example.com입니다. 이메일은 표준 OIDC 클레임입니다.
email: "alice@example.com"
# Alice는 admins와 devs 그룹의 멤버입니다.
groups: ["admins", "devs"]
# 그녀는 prod와 staging 환경에 접근할 수 있습니다.
env: ["prod", "staging"]

아이덴티티 프로바이더에 의해 외부 속성 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: ['*']

github.yaml이라는 GitHub 커넥터는 octocats 조직의 cyber 팀의 모든 멤버를 sso-users 역할에 매핑합니다:

kind: github
version: v3
metadata:
  name: github
spec:
  # GitHub OAuth app의 클라이언트 ID
  client_id: client-id
  # GitHub OAuth app의 클라이언트 시크릿
  client_secret: secret-data-here
  # 웹 UI 로그인 화면에 표시될 커넥터 이름
  display: GitHub
  # 성공적인 인증 후 호출될 콜백 URL
  redirect_url: https://teleport.example.com/v1/webapi/github/callback
  # org/team 멤버십을 허용된 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

#> Profile URL:        https://teleport.example.com:443
#  Logged in as:       bob
#  Cluster:            teleport.example.com
#  Roles:              sso-users*
#  Logins:             bob
#  Kubernetes:         enabled
#  Kubernetes groups:  edit
#  Valid until:        2021-03-26 07:13:57 -0700 PDT [valid for 12h0m0s]
#  Extensions:         permit-port-forwarding, permit-pty

$ tsh login --proxy=mytenant.teleport.sh --auth=github

#> Profile URL:        https://mytenant.teleport.sh:443
#  Logged in as:       bob
#  Cluster:            mytenant.teleport.sh
#  Roles:              sso-users*
#  Logins:             bob
#  Kubernetes:         enabled
#  Kubernetes groups:  edit
#  Valid until:        2021-03-26 07:13:57 -0700 PDT [valid for 12h0m0s]
#  Extensions:         permit-port-forwarding, permit-pty

보간 규칙#

관리자는 싱글 사인온 중에 아이덴티티 프로바이더가 반환하는 속성을 구성하고 Teleport에 제공할 수 있습니다. 몇 가지 시나리오를 검토하고 Teleport가 변수를 어떻게 보간하는지 살펴보겠습니다.

Alice 사용자 항목의 속성 목록으로 돌아가 보겠습니다:

# Alice의 이메일은 alice@example.com입니다. 이메일은 표준 OIDC 클레임입니다.
email: "alice@example.com"
# Alice는 admins와 devs 그룹의 멤버입니다.
groups: ["admins", "devs"]
# 그녀는 prod와 staging 환경에 접근할 수 있습니다.
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: ['*']

Alice의 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: ['*']

사용 가능한 보간 함수#

사용 가능한 보간 함수는 다음과 같습니다:

외부 이메일 아이덴티티로 작업하기#

SSO 프로바이더는 그룹을 보내는 것과 함께 사용자의 이메일 주소도 제공합니다. 많은 조직에서 사람들이 시스템에 로그인하는 데 사용하는 사용자 이름은 이메일 주소의 첫 번째 부분, 즉 "로컬" 부분과 동일합니다.

예를 들어, dave.smith@example.com은 dave.smith라는 사용자 이름으로 로그인할 수 있습니다. Teleport는 이메일 주소의 첫 번째 부분을 추출하여 사용자 이름으로 사용할 수 있는 편리한 방법을 제공합니다. 이것이 {{email.local}} 함수입니다.

아이덴티티 프로바이더에서 보낸 이메일 클레임({{external.email}}을 통해 접근 가능)이 이메일 주소를 포함하는 경우, @ 기호 앞의 "로컬" 부분을 다음과 같이 추출할 수 있습니다: {{email.local(external.email)}}

이것이 Teleport 역할에서 어떻게 보이는지 예시입니다:

kind: role
version: v5
metadata:
  name: sso_user
spec:
  allow:
    logins:
    # dave.smith@acme.com의 로컬 부분을 추출하므로 로그인은
    # 이제 dave.smith를 지원합니다.
    - '{{email.local(external.email)}}'
    node_labels:
      '*': '*'

접근 요청의 템플릿#

접근 요청과 검토자 요청 사양은 로그인, 레이블 등과 동일한 보간 시스템을 사용하지 않습니다. 대신 request와 review_requests 규칙의 claims_to_roles 절을 사용하여 일치시킬 하나 이상의 패턴을 지정할 수 있습니다.

예를 들어, request 구성에 대한 다음 규칙 템플릿이 있다고 가정합니다:

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']     # 값 캡처에서 역할 이름을 생성

예를 들어, Alice에게 product-admin 역할을 부여하고 projects 속성에 일부 항목을 추가할 수 있습니다:

kind: user
version: v2
metadata:
  name: alice
spec:
  roles: ['dev', 'product-admin']
  traits:
    projects: ['internal-tooling', 'product-alpha', 'product-beta']

이 경우 Alice는 RBAC 역할 access(정적 역할 목록에서)와 alpha-admin 및 beta-admin(claims_to_roles 매핑에서)에 대한 접근을 요청할 수 있습니다.

동일한 구문이 검토 요청에도 적용됩니다.