Infograb logo
액세스 제어 시작하기

Teleport에서는 모든 로컬, SSO 또는 로봇 사용자에게 여러 개의 역할을 할당할 수 있습니다.
역할은 데이터베이스, SSH 서버, Kubernetes 클러스터, Windows 데스크톱 및 웹 앱에 대한 액세스를 관리합니다.

우리는 로컬 사용자와 사전 설정된 역할부터 시작하여 SSO 사용자에게 역할을 할당하고
자신의 역할을 만드는 것으로 마무리하겠습니다.

전제 조건

  • 실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.

  • tctl 관리 도구와 tsh 클라이언트 도구.

    tctltsh 다운로드에 대한 지침은 설치를 방문하세요.

  • 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
    tsh login --proxy=teleport.example.com --user=email@example.com
    tctl 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-providerTeleport Terraform 공급자가 모든 지원되는 Teleport 리소스를 구성할 수 있도록 허용합니다.

로컬 사용자 Alice를 클러스터 editor로 초대합니다:

tctl users add alice --roles=editor

로컬 사용자 Alice를 클러스터 editorreviewer로 초대합니다:

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

다음 단계

Teleport 원문 보기