액세스 목록은 Teleport 사용자가 Teleport 내에서 관리되는 리소스에 장기적인 접근 권한을 부여받을 수 있게 합니다. 액세스 목록을 통해 관리자는 특정 역할과 트레이트에 대한 멤버십을 정기적으로 감사하고 제어할 수 있으며, 이는 Teleport의 기존 RBAC 시스템과 쉽게 연동됩니다.

이 가이드에서는 IaC 사용자 및 역할 가이드를 이어서, manager 역할을 가진 사용자가 특정 기준을 충족하는 사용자에게 support-engineer 역할을 부여할 수 있도록 설정합니다.

작동 방식#

액세스 목록은 Auth Service 백엔드에 저장된 리소스로 Teleport Auth Service에 등록됩니다. Teleport Auth Service는 클라이언트가 액세스 목록을 포함한 백엔드 리소스를 생성, 삭제 또는 수정할 수 있게 해주는 gRPC API를 제공합니다. Teleport Kubernetes Operator와 Terraform 프로바이더, 그리고 tctl 커맨드라인 도구는 Teleport Auth Service에 인증하고 gRPC API와 상호작용하여 액세스 목록을 관리할 수 있습니다.

기본적으로 액세스 목록은 IaC로 관리할 수 있지만 액세스 목록 멤버십은 관리할 수 없습니다. 액세스 목록의 목표는 접근 권한 부여와 검토를 분산화하는 것입니다. 관리자가 특정 지침 내에서 접근 권한을 부여하고 검토를 자동으로 시행함으로써, 사용자는 Teleport IaC를 중앙에서 관리하는 팀을 거치지 않고도 일반적인 접근 권한을 요청할 수 있습니다. 이를 통해 중앙 IaC/보안 팀의 부담이 줄어들고, 접근 검토자가 상황을 인지하게 되며, 요청 처리 시간이 단축되고, 접근 권한이 주기적으로 검토됩니다.

사전 요구 사항#

이 가이드를 따르려면 먼저 기본 사용자 및 역할 IaC 가이드를 완료해야 합니다. 해당 가이드의 사용자와 역할을 액세스 목록에서 재사용합니다.

1/3단계 - 매니페스트 작성#

권한 있는 역할 매니페스트 작성#

운영 서버에 대한 접근 권한을 부여하는 새 역할 support-engineer를 생성합니다. 이전 가이드의 engineer 역할은 dev 및 staging 서버에만 접근 권한을 부여했습니다.

kind: role
version: v7
metadata:
  name: support-engineer
spec:
  allow:
    logins: ['root', 'ubuntu', '{{internal.logins}}']
    node_labels:
      'env': ['production']

apiVersion: resources.teleport.dev/v1
kind: TeleportRoleV7
metadata:
  name: support-engineer
spec:
  allow:
    logins: [ 'root', 'ubuntu', '{{internal.logins}}' ]
    node_labels:
      'env': [ 'production' ]

resource "teleport_role" "support-engineer" {
  version = "v7"
  metadata = {
    name = "support-engineer"
  }

  spec = {
    allow = {
      logins = ["root", "ubuntu", "{{internal.logins}}"]
      node_labels = {
        env = ["production"]
      }
    }
  }
}

액세스 목록 매니페스트 작성#

이 단계에서는 alice와 같이 manager 역할을 가진 사용자가 engineer 역할을 가진 사용자에게 운영 환경 접근 권한을 부여할 수 있는 액세스 목록을 생성합니다.

version: v1
kind: access_list
metadata:
  name: support-engineers
spec:
  title: "Production access for support engineers"
  audit:
    recurrence:
      frequency: 6months
  description: "Use this Access List to grant access to production to your engineers enrolled in the support rotation."
  owners:
    - description: "manager of NA support team"
      name: alice
  ownership_requires:
    roles:
      - manager
  grants:
    roles:
      - support-engineer
  membership_requires:
    roles:
      - engineer

apiVersion: resources.teleport.dev/v1
kind: TeleportAccessList
metadata:
  name: support-engineers
spec:
  title: "Production access for support engineers"
  description: "Use this Access List to grant access to production to your engineers enrolled in the support rotation."
  audit:
    recurrence:
      frequency: 6months
  owners:
    - description: "manager of NA support team"
      name: alice
  ownership_requires:
    roles:
      - manager
  grants:
    roles:
      - support-engineer
  membership_requires:
    roles:
      - engineer

resource "teleport_access_list" "support-engineers" {
  header =  {
    version = "v1"
    metadata = {
      name = "support-engineers"
    }
  }

  spec = {
    title = "Production access for support engineers"
    description = "Use this Access List to grant access to production to your engineers enrolled in the support rotation."
    audit = {
      recurrence = {
        frequency = 6
      }
    }
    owners = [
      {
        description = "manager of NA support team"
        name = "alice"
      }
    ]
    ownership_requires = {
      roles = ["manager"]
    }
    grants = {
      roles = ["support-engineer"]
    }
    membership_requires = {
      roles = ["engineer"]
    }
  }
}

2/3단계 - 매니페스트 적용#

$ tctl create -f privileged-role.yaml
role 'support-engineer' has been created

$ tctl create -f accesslist.yaml
Access list "support-engineers" has been created

$ kubectl apply -n "$OPERATOR_NAMESPACE" -f privileged-role.yaml
teleportrolev7.resources.teleport.dev/support-engineer created

$ kubectl apply -n "$OPERATOR_NAMESPACE" -f accesslist.yaml
teleportaccesslist.resources.teleport.dev/support-engineers

$ terraform plan
[...]
Plan: 2 to add, 0 to change, 0 to destroy.

$ terraform apply
teleport_access_list.support-engineers: Creating...
teleport_role.support-engineer: Creating...
teleport_role.support-engineer: Creation complete after 0s [id=support-engineer]
teleport_access_list.support-engineers: Creation complete after 0s [id=support-engineers]

3/3단계 - alice로 로그인하여 bob에게 접근 권한 부여#

이제 alice가 support-engineer 역할을 엔지니어에게 부여할 수 있는 액세스 목록이 생성되었습니다.

alice로 로그인하여 bob을 support-engineers 액세스 목록에 추가할 수 있습니다.

# alice로 로그인
$ tsh login --proxy <your-cluster-domain>:<port> --user alice

# tctl acl users add <access-list-name> <user> [<expires>] [<reason>]
$ tctl acl users add support-engineers bob "" "Bob is now part of the on-call support rotation"

$ tctl acl users ls support-engineers
Members of support-engineers:
- bob

Terraform으로 액세스 목록 멤버 관리#

Terraform으로 액세스 목록을 관리할 때는 두 가지 Terraform 리소스를 사용합니다: teleport_access_list와 teleport_access_list_member. 이 섹션에서는 액세스 목록 멤버를 관리하기 위해 Teleport Terraform 구성을 조정하는 방법과 Terraform 대 Web UI 및 tctl을 사용하는 경우의 차이점을 설명합니다.

정적 액세스 목록과 기본 액세스 목록#

tctl 또는 Web UI를 사용하여 생성하는 기본 액세스 목록은 .spec.type 필드가 설정되지 않았거나 null 또는 빈 문자열로 설정되어 있습니다. 결과적으로:

• 감사가 필요합니다. Terraform 리소스에서 .spec.audit이 지정되지 않은 경우 Teleport는 기본값을 할당합니다. 정적 액세스 목록은 Web UI에서 주기적으로 검토해야 합니다.
• 멤버는 Web UI 및 tctl로만 관리할 수 있습니다. 이러한 목록의 진실 소스는 Teleport이므로 Terraform으로 멤버를 관리할 수 없습니다.

정적 액세스 목록은 .spec.type 필드가 "static"으로 설정되어 있습니다. 기본 액세스 목록과 다른 점은:

• 감사를 지원하지 않습니다. Teleport는 .spec.audit 필드를 무시합니다.
• 멤버를 Terraform으로 관리할 수 있습니다.

정적 액세스 목록의 경우, 멤버십의 진실 소스는 Terraform 구성이므로 감사가 지원되지 않습니다. 대신 Terraform 구성을 수정할 때 멤버를 검토할 수 있습니다.

정적 액세스 목록 지정#

이전에 생성한 액세스 목록을 편집하여 유형을 "static"으로 설정합니다. Teleport는 정적 액세스 목록에서 spec.audit 필드를 무시하지만, 명확성을 위해 아래와 같이 제거할 수 있습니다:

  resource "teleport_access_list" "support-engineers" {
    header =  {
      version = "v1"
      metadata = {
        name = "support-engineers"
      }
    }

    spec = {
+     type = "static"
      title = "Production access for support engineers"
      description = "Use this Access List to grant access to production to your engineers enrolled in the support rotation."
-     audit = {
-     recurrence = {
-       frequency = 6
-     }
-   }
    }
  # remaining fields truncated
  }

액세스 목록에 사용자 할당#

사용자를 액세스 목록의 멤버로 할당하려면 teleport_access_list_member 리소스를 선언하고 spec.membership_kind를 사용자임을 나타내는 1로 설정합니다:

resource "teleport_access_list_member" "developers_alice" {
  header = {
    version = "v1"
    metadata = {
      name = "alice" # Teleport user name
    }
  }
  spec = {
    access_list     = teleport_access_list.support-engineers.id
    membership_kind = 1 # 1 for "MEMBERSHIP_KIND_USER", 2 for "MEMBERSHIP_KIND_LIST"
  }
}

resource "teleport_access_list_member" "developers_bob" {
  header = {
    version = "v1"
    metadata = {
      name = "bob"
    }
  }
  spec = {
    access_list     = teleport_access_list.support-engineers.id
    membership_kind = 1 # 1 for "MEMBERSHIP_KIND_USER", 2 for "MEMBERSHIP_KIND_LIST"
  }
}

두 멤버의 spec.access_list가 앞서 생성한 support-engineers 액세스 목록의 ID를 참조하고 있습니다.

중첩 액세스 목록 할당#

정적 액세스 목록을 사용하면 중첩 액세스 목록을 할당할 수도 있습니다. 예를 들어 다음 teleport_access_list_member 리소스를 고려합니다:

resource "teleport_access_list_member" "db_access_staging_developers" {
  header = {
    version = "v1"
    metadata = {
      name = teleport_access_list.technical-account-managers.id
    }
  }
  spec = {
    access_list     = teleport_access_list.support-engineers.id
    membership_kind = 2 # 1 for "MEMBERSHIP_KIND_USER", 2 for "MEMBERSHIP_KIND_LIST"
  }
}

이 리소스는 spec.membership_kind가 2로, 중첩 액세스 목록임을 나타냅니다. 멤버의 이름은 이 가이드에서 표시되지 않은 다른 액세스 목록인 technical-account-managers의 ID입니다. 이를 통해 Terraform 프로바이더가 technical-account-managers 액세스 목록을 support-engineers 내의 중첩 액세스 목록으로 할당합니다.

Okta 또는 Microsoft Entra ID 그룹에 접근 권한 부여#

Okta 연동을 통해 Okta 그룹 및 앱을 동기화하여 Teleport 액세스 목록으로 사용할 수 있으며, Microsoft Entra ID 연동을 통해 그룹을 동기화하여 Teleport 액세스 목록으로 사용할 수 있습니다.

Terraform에서 이러한 연동을 기반으로 하는 액세스 목록에 권한을 부여하려면, Web UI에서 액세스 목록으로 이동하여 URL에서 마지막 경로 세그먼트를 복사합니다(예: https://example.teleport.sh/web/accesslists/00gt3c8z9ukePm5uF697의 경우 00gt3c8z9ukePm5uF697). 이것이 Teleport에서 액세스 목록 리소스의 이름입니다.

예를 들어, 다음 teleport_access_list_member는 Okta 연동을 통해 관리되는 액세스 목록을 support-engineers 액세스 목록의 하위 목록으로 구성합니다:

resource "teleport_access_list_member" "db_access_staging_okta_group" {
  header = {
    version = "v1"
    metadata = {
      name = "00gt3c8z9ukePm5uF697"
    }
  }
  spec = {
    access_list     = teleport_access_list.support-engineers.id
    membership_kind = 2 # 1 for "MEMBERSHIP_KIND_USER", 2 for "MEMBERSHIP_KIND_LIST"
  }
}

Microsoft Entra ID 연동을 통해 관리되는 액세스 목록의 경우, 이름은 b1a6a594-a4ac-51d1-a6f6-1746a413a79a와 유사합니다.

Web UI에서 생성한 액세스 목록을 Terraform으로 가져오기#

Web UI에서 생성한 액세스 목록을 Terraform 모듈로 가져오는 것은 일반적으로 불가능합니다. 액세스 목록을 가져올 수는 있지만 UI에서 생성된 액세스 목록은 정적 유형이 아니므로 멤버를 Terraform으로 관리할 수 없습니다. 연동(예: Okta 또는 Microsoft Entra ID)으로 생성된 액세스 목록에도 동일하게 적용됩니다. 다른 Terraform 설정(다른 상태)으로 생성된 기존 정적 목록은 가져올 수 있고 Terraform으로 멤버를 관리할 수 있지만, 이러한 상황은 드뭅니다.

권장하는 해결책은 Terraform으로 관리되는 정적 액세스 목록을 생성하고 이 목록을 기존 액세스 목록의 멤버로 만드는 것입니다. 이렇게 하면 Terraform으로 관리되는 정적 액세스 목록의 멤버들이 기존 액세스 목록의 권한을 상속받게 됩니다.

다음 단계#

지원되는 모든 액세스 목록 필드는 액세스 목록 참조에서 확인할 수 있습니다.