InfoGrab DocsInfoGrab Docs

데이터베이스 접근 제어

요약

데이터베이스 접근 제어는 데이터베이스와 그 내부 데이터에 대한 역할 기반 접근 제어를 구성할 수 있는 Teleport 기능입니다. 이 페이지는 Teleport 역할 및 데이터베이스 객체 가져오기 규칙의 구성 옵션에 대해 설명합니다.

데이터베이스 접근 제어는 데이터베이스와 그 내부 데이터에 대한 역할 기반 접근 제어를 구성할 수 있는 Teleport 기능입니다. 데이터베이스 접근 제어를 통해 사용자가 필요한 데이터만 관리할 수 있는 권한을 갖도록 보장할 수 있습니다.

이 페이지는 Teleport 역할 및 데이터베이스 객체 가져오기 규칙의 구성 옵션에 대해 설명합니다. 이러한 옵션을 사용하면 사용자가 Teleport로 보호되는 데이터베이스에 대해 수행할 수 있는 작업을 제한할 수 있습니다.

작동 방식#

접근 제어는 두 수준의 세분성을 포함합니다:

  • 데이터베이스 서버: Teleport 클러스터에 등록된 데이터베이스 리소스.
  • 데이터베이스 객체: 테이블, 뷰 또는 저장 프로시저.

데이터베이스 서버와 데이터베이스 객체 모두에 대해 데이터베이스 접근 제어는 Teleport 레이블을 기반으로 접근을 허용하거나 거부합니다. Teleport에 데이터베이스를 등록할 때 데이터베이스와 관련된 레이블을 구성할 수 있습니다. 데이터베이스 객체의 경우 Teleport Database Service가 가져오기 규칙 내에서 구성된 레이블과 일치하는 데이터베이스에서 가져온 데이터베이스 객체에 레이블을 적용하도록 지시하는 가져오기 규칙을 정의할 수 있습니다.

사용자가 데이터베이스에 연결하면 Database Service는 레이블을 사용자의 Teleport 역할에 대해 선택적으로 확인하여 권한을 부여합니다.

Database Service는 연결 기간 동안 객체 수준 권한을 부여하고 연결이 종료되면 자동으로 취소합니다.

Teleport 역할 및 예시에 대한 더 일반적인 설명은 RBAC를 참조하십시오. 이 섹션은 데이터베이스 접근을 위한 RBAC 구성에 초점을 맞춥니다.

Warning

데이터베이스 객체에 대한 데이터베이스 접근 제어는 PostgreSQL 데이터베이스만 지원합니다.

역할 구성#

Teleport의 역할 리소스는 데이터베이스 접근을 제한하기 위한 다음 수단을 제공합니다:

kind: role
version: v5
metadata:
  name: developer
spec:
  allow:
    # 이 역할이 접근할 수 있는 데이터베이스 인스턴스에 대한 레이블 선택기.
    #
    # 이것들은 데이터베이스 서비스에 설정된 정적/동적 레이블과 매칭됩니다.
    db_labels:
      environment: ["dev", "stage"]

    # 이 역할이 연결할 수 있는 데이터베이스 계정 이름.
    db_users: ["viewer", "editor"]

    # 이 역할이 연결할 수 있는 데이터베이스 이름.
    #
    # 이것은 "db_service"의 "name" 필드와 동일하지 않으며,
    # 특정 데이터베이스 인스턴스 내의 데이터베이스 이름입니다.
    #
    # 또한 데이터베이스 이름은 PostgreSQL, MongoDB 및 Cloud Spanner 데이터베이스에서만 적용됩니다.
    db_names: ["main", "metrics", "postgres"]

와일드카드를 사용하여 모든 데이터베이스 이름/사용자와 매칭할 수 있습니다.

예를 들어, 다음 역할은 내부 "postgres" 데이터베이스/사용자를 제외한 프로덕션 데이터베이스 내 모든 데이터베이스/사용자에 대한 접근을 허용합니다:

kind: role
version: v5
metadata:
  name: developer
spec:
  allow:
    db_labels:
      environment: ["prod"]
    db_users: ["*"]
    db_names: ["*"]
  deny:
    db_users: ["postgres"]
    db_names: ["postgres"]
Deny Rules

거부 규칙은 탐욕적으로 매칭됩니다. 위 예시에서 "postgres" 데이터베이스 계정을 사용하려는 데이터베이스 연결 시도(데이터베이스 인스턴스나 데이터베이스 이름에 관계없이) 또는 "postgres" 데이터베이스 이름을 사용하려는 연결 시도(데이터베이스 인스턴스나 데이터베이스 계정에 관계없이)는 거부됩니다.

데이터베이스 이름#

서로 다른 데이터베이스 서버가 논리적 데이터베이스를 처리하는 방식에는 차이가 있으며, 이로 인해 연결 시도에 db_names 역할 필드가 적용되는 방식도 달라집니다.

PostgreSQL은 여러 개의 논리적 데이터베이스를 지원하며, 각 논리적 데이터베이스는 여러 스키마를 포함할 수 있습니다. 다른 데이터베이스로 변경하려면 사용자는 현재 데이터베이스에서 연결을 끊고 새 연결을 설정해야 합니다. PostgreSQL 연결 시도 중에는 db_names 필드가 사용자가 연결하려는 논리적 데이터베이스의 이름에 대해 확인됩니다.

PostgreSQL과 마찬가지로 Teleport는 MongoDB 및 Cloud Spanner 데이터베이스에 대해서도 db_names를 적용합니다.

MySQL에서 논리적 "데이터베이스"와 "스키마"는 서로 동의어이며, 연결 후 사용자가 갖는 권한의 범위는 데이터베이스 내 계정에 설정된 권한 부여에 의해 결정됩니다. 따라서 db_names 역할 필드는 현재 MySQL 연결 시도에는 적용되지 않습니다.

템플릿 변수#

다른 역할 필드와 유사하게 db_* 필드는 템플릿 변수를 지원합니다.

external.xyz 특성(trait)은 외부 싱글 사인온 제공자의 값으로 교체됩니다. OIDC의 경우 "xyz" 클레임의 값으로 교체됩니다. SAML의 경우 "xyz" 어설션 값으로 교체됩니다.

Teleport 역할에서 특성이 작동하는 방식에 대한 자세한 내용은 접근 제어 참조를 참조하십시오.

예를 들어, 사용자의 Okta databases 어설션에서 허용된 데이터베이스 이름을 할당하려는 경우 역할이 다음과 같이 보일 수 있습니다:

spec:
  allow:
    db_names: ["{{external.databases}}"]

{{internal.db_users}}{{internal.db_names}} 변수는 허용된 데이터베이스 계정과 이름을 원격 클러스터와 공유할 수 있도록 합니다. 이 변수들은 루트 클러스터에서 연결하는 원격 사용자의 해당 속성으로 교체됩니다.

예를 들어, 루트 클러스터의 사용자가 다음과 같은 역할을 가지고 있다고 가정합니다:

spec:
  allow:
    db_users: ["postgres"]
    db_names: ["postgres"]

리프 클러스터의 역할은 사용자의 허용된 데이터베이스 계정과 이름을 사용하도록 설정할 수 있습니다:

spec:
  allow:
    db_users: ["{{internal.db_users}}"]
    db_names: ["{{internal.db_names}}"]

데이터베이스 객체 가져오기 규칙#

Teleport의 데이터베이스 객체 가져오기 규칙은 Teleport로 가져온 데이터베이스 객체에 적용할 레이블을 정의하는 리소스입니다. 특정 객체가 어떤 규칙과도 일치하지 않으면 가져오지 않습니다.

기본 가져오기 규칙#

기본적으로 가져오기 규칙이 없는 경우(예: 새 클러스터를 생성하거나 모든 규칙을 삭제한 경우) Teleport는 시작 시 자동으로 import_all_objects 규칙을 생성합니다:

kind: db_object_import_rule
metadata:
  name: import_all_objects
spec:
  # Priority determines how important the rule is, with lower number indicating lower priority.
  # In case of conflicts, when the same label is applied by two rules,
  # the label applied by rule with higher priority wins.
  priority: 0
  # database_labels is a filter specifying which database resources are in scope of this rule.
  database_labels:
  - name: '*'
    values:
    - '*'
  # Each mapping, if matched, introduces a set of labels applied to database object.
  # Database objects without labels are not imported.
  mappings:
  - add_labels:
      database: '{{obj.database}}'
      object_kind: '{{obj.object_kind}}'
      name: '{{obj.name}}'
      protocol: '{{obj.protocol}}'
      schema: '{{obj.schema}}'
      database_service_name: '{{obj.database_service_name}}'
    # match adds objects to be imported; it cannot be empty.
    match:
      # list of all table names
      table_names:
      - '*'
  # Additional mappings can be added here.
  # - add_labels: ...
version: v1

이 규칙은 모든 객체를 가져오고, 템플릿 구문을 사용하여 객체의 고유한 속성으로 레이블을 지정합니다.

기본 가져오기 규칙 사용자 정의#

다른 Teleport 리소스와 마찬가지로 기본 db_object_import_rule을 수정할 수 있습니다.

예를 들어, 특정 테이블을 개발자가 읽기 전용 또는 읽기/쓰기 방식으로 접근할 수 있도록 지정하는 다음 규칙을 살펴보겠습니다:

kind: db_object_import_rule
metadata:
  name: ownership_nonprod
spec:
  priority: 100
  database_labels:
  # Affect `dev` and `staging` environments.
  # Prod environment may have a different rule.
  - name: 'env'
    values:
    - 'staging'
    - 'dev'
  mappings:
  # Apply project label
  - add_labels:
      project: horizon
    # match section is mandatory and must contain at least one non-empty subsection
    match:
      table_names:
      - '*'
    # scope is the optional section which enables further filtering of objects by database and schema names. When omitted, this filtering is disabled.
    scope:
      database_names:
      - 'horizon'
      - 'horizon_v2'
      schema_names:
      - 'application'
      - 'data_import'
  # Add `dept: hr` label for respective tables.
  - add_labels:
      dept: hr
    match:
      table_names:
      - '*'
    scope:
      schema_names:
      - 'recruitment'
      - 'salaries'
      - 'pto'
      - 'hr_scratchpad'
version: v1

기본 가져오기 규칙 비활성화#

Teleport는 최소한 하나의 가져오기 규칙이 정의되어 있을 것으로 예상합니다. 정의되어 있지 않으면 Teleport Auth Service가 시작 시 기본 가져오기 규칙을 생성합니다.

데이터베이스 객체를 전혀 가져오고 싶지 않다면 어떤 데이터베이스와도 일치하지 않는 규칙을 생성하십시오. 아래 예시에서는 매칭되는 레이블 값 목록이 비어 있으므로 어떤 데이터베이스도 이 선택기와 일치하지 않습니다.

kind: db_object_import_rule
metadata:
  name: import_no_objects
spec:
  database_labels:
  - {}
  mappings:
  - {}
version: v1

사용자 정의 규칙을 생성하고 기본 규칙을 제거합니다:

$ tctl create -f import_no_objects.yaml
rule "import_no_objects" has been created
$ tctl rm db_object_import_rule/import_all_objects
Rule "import_all_objects" has been deleted

데이터베이스 관리자 사용자#

데이터베이스 관리자 사용자는 최종 사용자에게 권한을 부여하는 역할을 담당합니다. 데이터베이스 객체 가져오기 규칙을 사용하기 전에 데이터베이스 관리자 사용자를 지정해야 합니다. 데이터베이스 관리자 사용자를 지정하려면, Teleport Database Service를 실행하는 에이전트에 대한 동적 데이터베이스 리소스 또는 구성 파일에 다음을 추가하십시오:

kind: db
version: v3
metadata:
  # ...
spec:
  # ...
  admin_user:
    name: "teleport-admin"
db_service:
  enabled: true
  databases:
  - name: "example"
    # ...
    admin_user:
      name: "teleport-admin"

이 경우 Teleport Database Service는 객체 가져오기 규칙을 실행하기 위해 teleport-admin이라는 사용자를 활성화할 것으로 예상합니다. 관리자 사용자가 데이터베이스에서 사용자를 관리하는 데 필요한 권한을 보유하고 있는지 확인하십시오. 그렇지 않으면 데이터베이스 구성 방식에 따라 객체 가져오기 규칙이 실패할 수 있습니다:

$ tsh db connect postgres-db --db-name postgres --db-user teleport-user
psql: error: connection to server at "localhost" (::1), port 50800 failed: Connection refused
	Is the server running on that host and accepting TCP/IP connections?
connection to server at "localhost" (127.0.0.1), port 50800 failed: your Teleport role requires automatic database user provisioning but an attempt to activate database user "teleport-user" failed due to the following error: ERROR: permission denied for table pg_subscription (SQLSTATE 42501)
ERROR: exit status 2

데이터베이스 객체 권한 규칙 실행#

Teleport Database Service는 사용자가 데이터베이스에 연결하도록 허용하기 전에 사용자와 관련된 역할을 확인합니다.

데이터베이스 연결 중에 데이터베이스 객체 권한을 부여하려면 사용자가 다음 특정 기준을 충족하는 역할과 연관되어 있어야 합니다:

  • spec.allow.db_labels가 특정 데이터베이스의 데이터베이스 레이블과 일치해야 합니다.
  • 데이터베이스 사용자 자동 프로비저닝이 활성화되어 있어야 합니다 (spec.options.create_db_user_modeoff로 설정되지 않았거나 spec.options.create_db_user: true인 경우).
  • spec.allow.db_permissions.match의 레이블 키/값 쌍이 특정 데이터베이스 객체의 레이블과 일치해야 합니다.

사용자는 동일한 데이터베이스에 대해 여러 개의 동시 연결을 유지할 수 있습니다. 모든 연결은 동일한 권한을 가져야 하며, 그렇지 않으면 새 연결이 거부됩니다. 마지막으로 활성화된 연결이 종료되면 모든 사용자 권한이 자동으로 취소됩니다.

테이블에 있는 레이블은 적절한 역할과 매칭되어야 합니다. 다음은 ownership_nonprod 규칙에 의해 적용된 dept 레이블을 활용하여 데이터베이스 내 HR 레코드에 대한 읽기 전용 접근 권한을 부여하는 역할의 예시입니다. hr_scratchpad 테이블은 추가로 편집 가능하게 설정됩니다. 반면 dept: sales로 레이블이 지정된 객체는 사용자가 받았을 수 있는 모든 권한을 제거하여 사용할 수 없게 만듭니다. 와일드카드 권한은 spec의 deny 부분(spec.deny.db_permissions)에서만 허용됩니다:

version: v7
kind: role
metadata:
  name: dept_hr_permissions
spec:
  allow:
    db_labels:
      '*': '*'
    db_names:
    - '*'
    db_permissions:
    # default permission: read-only
    - match:
        object_kind: table
        dept: hr
      permissions:
      - SELECT
    # extra permissions for select tables
    - match:
        object_kind: table
        dept: hr
        name: hr_scratchpad
      permissions:
      - SELECT
      - UPDATE
      - DELETE
      - INSERT
  deny:
    db_permissions:
    # explicitly disallow any interaction with `dept: sales` tables.
    - match:
        dept: sales
      permissions:
      - '*'
  options:
    create_db_user_mode: keep

객체 가져오기 규칙 문제 해결#

데이터베이스 객체 가져오기 문제를 진단하려면 Teleport Database Service 로그를 참조하십시오. 이 로그에는 데이터베이스에서 가져온 객체 수, 가져온 객체 수(그 차이는 가져오기 규칙과 일치하지 않은 객체를 의미), 사용자에게 권한이 부여된 객체 수가 표시됩니다:

INFO [DB:SERVIC] Database objects fetched from the database (table:75). db:my-postgres id:b4a33740-1d82-4a8d-b2be-2aa90ae9d2eb total:75 postgres/users.go:212
INFO [DB:SERVIC] Database objects imported (table:75). db:my-postgres err_count:0 id:b4a33740-1d82-4a8d-b2be-2aa90ae9d2eb total:75 postgres/users.go:216
INFO [DB:SERVIC] Calculated database permissions: "INSERT": 75 objects (table:75), "SELECT": 75 objects (table:75), "UPDATE": 75 objects (table:75). db:my-postgres id:b4a33740-1d82-4a8d-b2be-2aa90ae9d2eb user:teleport-user postgres/users.go:223

데이터베이스 접근 제어

Teleport v18.9
원문 보기
요약

데이터베이스 접근 제어는 데이터베이스와 그 내부 데이터에 대한 역할 기반 접근 제어를 구성할 수 있는 Teleport 기능입니다. 이 페이지는 Teleport 역할 및 데이터베이스 객체 가져오기 규칙의 구성 옵션에 대해 설명합니다.

데이터베이스 접근 제어는 데이터베이스와 그 내부 데이터에 대한 역할 기반 접근 제어를 구성할 수 있는 Teleport 기능입니다. 데이터베이스 접근 제어를 통해 사용자가 필요한 데이터만 관리할 수 있는 권한을 갖도록 보장할 수 있습니다.

이 페이지는 Teleport 역할 및 데이터베이스 객체 가져오기 규칙의 구성 옵션에 대해 설명합니다. 이러한 옵션을 사용하면 사용자가 Teleport로 보호되는 데이터베이스에 대해 수행할 수 있는 작업을 제한할 수 있습니다.

작동 방식#

접근 제어는 두 수준의 세분성을 포함합니다:

  • 데이터베이스 서버: Teleport 클러스터에 등록된 데이터베이스 리소스.
  • 데이터베이스 객체: 테이블, 뷰 또는 저장 프로시저.

데이터베이스 서버와 데이터베이스 객체 모두에 대해 데이터베이스 접근 제어는 Teleport 레이블을 기반으로 접근을 허용하거나 거부합니다. Teleport에 데이터베이스를 등록할 때 데이터베이스와 관련된 레이블을 구성할 수 있습니다. 데이터베이스 객체의 경우 Teleport Database Service가 가져오기 규칙 내에서 구성된 레이블과 일치하는 데이터베이스에서 가져온 데이터베이스 객체에 레이블을 적용하도록 지시하는 가져오기 규칙을 정의할 수 있습니다.

사용자가 데이터베이스에 연결하면 Database Service는 레이블을 사용자의 Teleport 역할에 대해 선택적으로 확인하여 권한을 부여합니다.

Database Service는 연결 기간 동안 객체 수준 권한을 부여하고 연결이 종료되면 자동으로 취소합니다.

Teleport 역할 및 예시에 대한 더 일반적인 설명은 RBAC를 참조하십시오. 이 섹션은 데이터베이스 접근을 위한 RBAC 구성에 초점을 맞춥니다.

Warning

데이터베이스 객체에 대한 데이터베이스 접근 제어는 PostgreSQL 데이터베이스만 지원합니다.

역할 구성#

Teleport의 역할 리소스는 데이터베이스 접근을 제한하기 위한 다음 수단을 제공합니다:

kind: role
version: v5
metadata:
  name: developer
spec:
  allow:
    # 이 역할이 접근할 수 있는 데이터베이스 인스턴스에 대한 레이블 선택기.
    #
    # 이것들은 데이터베이스 서비스에 설정된 정적/동적 레이블과 매칭됩니다.
    db_labels:
      environment: ["dev", "stage"]

    # 이 역할이 연결할 수 있는 데이터베이스 계정 이름.
    db_users: ["viewer", "editor"]

    # 이 역할이 연결할 수 있는 데이터베이스 이름.
    #
    # 이것은 "db_service"의 "name" 필드와 동일하지 않으며,
    # 특정 데이터베이스 인스턴스 내의 데이터베이스 이름입니다.
    #
    # 또한 데이터베이스 이름은 PostgreSQL, MongoDB 및 Cloud Spanner 데이터베이스에서만 적용됩니다.
    db_names: ["main", "metrics", "postgres"]

와일드카드를 사용하여 모든 데이터베이스 이름/사용자와 매칭할 수 있습니다.

예를 들어, 다음 역할은 내부 "postgres" 데이터베이스/사용자를 제외한 프로덕션 데이터베이스 내 모든 데이터베이스/사용자에 대한 접근을 허용합니다:

kind: role
version: v5
metadata:
  name: developer
spec:
  allow:
    db_labels:
      environment: ["prod"]
    db_users: ["*"]
    db_names: ["*"]
  deny:
    db_users: ["postgres"]
    db_names: ["postgres"]
Deny Rules

거부 규칙은 탐욕적으로 매칭됩니다. 위 예시에서 "postgres" 데이터베이스 계정을 사용하려는 데이터베이스 연결 시도(데이터베이스 인스턴스나 데이터베이스 이름에 관계없이) 또는 "postgres" 데이터베이스 이름을 사용하려는 연결 시도(데이터베이스 인스턴스나 데이터베이스 계정에 관계없이)는 거부됩니다.

데이터베이스 이름#

서로 다른 데이터베이스 서버가 논리적 데이터베이스를 처리하는 방식에는 차이가 있으며, 이로 인해 연결 시도에 db_names 역할 필드가 적용되는 방식도 달라집니다.

PostgreSQL은 여러 개의 논리적 데이터베이스를 지원하며, 각 논리적 데이터베이스는 여러 스키마를 포함할 수 있습니다. 다른 데이터베이스로 변경하려면 사용자는 현재 데이터베이스에서 연결을 끊고 새 연결을 설정해야 합니다. PostgreSQL 연결 시도 중에는 db_names 필드가 사용자가 연결하려는 논리적 데이터베이스의 이름에 대해 확인됩니다.

PostgreSQL과 마찬가지로 Teleport는 MongoDB 및 Cloud Spanner 데이터베이스에 대해서도 db_names를 적용합니다.

MySQL에서 논리적 "데이터베이스"와 "스키마"는 서로 동의어이며, 연결 후 사용자가 갖는 권한의 범위는 데이터베이스 내 계정에 설정된 권한 부여에 의해 결정됩니다. 따라서 db_names 역할 필드는 현재 MySQL 연결 시도에는 적용되지 않습니다.

템플릿 변수#

다른 역할 필드와 유사하게 db_* 필드는 템플릿 변수를 지원합니다.

external.xyz 특성(trait)은 외부 싱글 사인온 제공자의 값으로 교체됩니다. OIDC의 경우 "xyz" 클레임의 값으로 교체됩니다. SAML의 경우 "xyz" 어설션 값으로 교체됩니다.

Teleport 역할에서 특성이 작동하는 방식에 대한 자세한 내용은 접근 제어 참조를 참조하십시오.

예를 들어, 사용자의 Okta databases 어설션에서 허용된 데이터베이스 이름을 할당하려는 경우 역할이 다음과 같이 보일 수 있습니다:

spec:
  allow:
    db_names: ["{{external.databases}}"]

{{internal.db_users}}{{internal.db_names}} 변수는 허용된 데이터베이스 계정과 이름을 원격 클러스터와 공유할 수 있도록 합니다. 이 변수들은 루트 클러스터에서 연결하는 원격 사용자의 해당 속성으로 교체됩니다.

예를 들어, 루트 클러스터의 사용자가 다음과 같은 역할을 가지고 있다고 가정합니다:

spec:
  allow:
    db_users: ["postgres"]
    db_names: ["postgres"]

리프 클러스터의 역할은 사용자의 허용된 데이터베이스 계정과 이름을 사용하도록 설정할 수 있습니다:

spec:
  allow:
    db_users: ["{{internal.db_users}}"]
    db_names: ["{{internal.db_names}}"]

데이터베이스 객체 가져오기 규칙#

Teleport의 데이터베이스 객체 가져오기 규칙은 Teleport로 가져온 데이터베이스 객체에 적용할 레이블을 정의하는 리소스입니다. 특정 객체가 어떤 규칙과도 일치하지 않으면 가져오지 않습니다.

기본 가져오기 규칙#

기본적으로 가져오기 규칙이 없는 경우(예: 새 클러스터를 생성하거나 모든 규칙을 삭제한 경우) Teleport는 시작 시 자동으로 import_all_objects 규칙을 생성합니다:

kind: db_object_import_rule
metadata:
  name: import_all_objects
spec:
  # Priority determines how important the rule is, with lower number indicating lower priority.
  # In case of conflicts, when the same label is applied by two rules,
  # the label applied by rule with higher priority wins.
  priority: 0
  # database_labels is a filter specifying which database resources are in scope of this rule.
  database_labels:
  - name: '*'
    values:
    - '*'
  # Each mapping, if matched, introduces a set of labels applied to database object.
  # Database objects without labels are not imported.
  mappings:
  - add_labels:
      database: '{{obj.database}}'
      object_kind: '{{obj.object_kind}}'
      name: '{{obj.name}}'
      protocol: '{{obj.protocol}}'
      schema: '{{obj.schema}}'
      database_service_name: '{{obj.database_service_name}}'
    # match adds objects to be imported; it cannot be empty.
    match:
      # list of all table names
      table_names:
      - '*'
  # Additional mappings can be added here.
  # - add_labels: ...
version: v1

이 규칙은 모든 객체를 가져오고, 템플릿 구문을 사용하여 객체의 고유한 속성으로 레이블을 지정합니다.

기본 가져오기 규칙 사용자 정의#

다른 Teleport 리소스와 마찬가지로 기본 db_object_import_rule을 수정할 수 있습니다.

예를 들어, 특정 테이블을 개발자가 읽기 전용 또는 읽기/쓰기 방식으로 접근할 수 있도록 지정하는 다음 규칙을 살펴보겠습니다:

kind: db_object_import_rule
metadata:
  name: ownership_nonprod
spec:
  priority: 100
  database_labels:
  # Affect `dev` and `staging` environments.
  # Prod environment may have a different rule.
  - name: 'env'
    values:
    - 'staging'
    - 'dev'
  mappings:
  # Apply project label
  - add_labels:
      project: horizon
    # match section is mandatory and must contain at least one non-empty subsection
    match:
      table_names:
      - '*'
    # scope is the optional section which enables further filtering of objects by database and schema names. When omitted, this filtering is disabled.
    scope:
      database_names:
      - 'horizon'
      - 'horizon_v2'
      schema_names:
      - 'application'
      - 'data_import'
  # Add `dept: hr` label for respective tables.
  - add_labels:
      dept: hr
    match:
      table_names:
      - '*'
    scope:
      schema_names:
      - 'recruitment'
      - 'salaries'
      - 'pto'
      - 'hr_scratchpad'
version: v1

기본 가져오기 규칙 비활성화#

Teleport는 최소한 하나의 가져오기 규칙이 정의되어 있을 것으로 예상합니다. 정의되어 있지 않으면 Teleport Auth Service가 시작 시 기본 가져오기 규칙을 생성합니다.

데이터베이스 객체를 전혀 가져오고 싶지 않다면 어떤 데이터베이스와도 일치하지 않는 규칙을 생성하십시오. 아래 예시에서는 매칭되는 레이블 값 목록이 비어 있으므로 어떤 데이터베이스도 이 선택기와 일치하지 않습니다.

kind: db_object_import_rule
metadata:
  name: import_no_objects
spec:
  database_labels:
  - {}
  mappings:
  - {}
version: v1

사용자 정의 규칙을 생성하고 기본 규칙을 제거합니다:

$ tctl create -f import_no_objects.yaml
rule "import_no_objects" has been created
$ tctl rm db_object_import_rule/import_all_objects
Rule "import_all_objects" has been deleted

데이터베이스 관리자 사용자#

데이터베이스 관리자 사용자는 최종 사용자에게 권한을 부여하는 역할을 담당합니다. 데이터베이스 객체 가져오기 규칙을 사용하기 전에 데이터베이스 관리자 사용자를 지정해야 합니다. 데이터베이스 관리자 사용자를 지정하려면, Teleport Database Service를 실행하는 에이전트에 대한 동적 데이터베이스 리소스 또는 구성 파일에 다음을 추가하십시오:

kind: db
version: v3
metadata:
  # ...
spec:
  # ...
  admin_user:
    name: "teleport-admin"
db_service:
  enabled: true
  databases:
  - name: "example"
    # ...
    admin_user:
      name: "teleport-admin"

이 경우 Teleport Database Service는 객체 가져오기 규칙을 실행하기 위해 teleport-admin이라는 사용자를 활성화할 것으로 예상합니다. 관리자 사용자가 데이터베이스에서 사용자를 관리하는 데 필요한 권한을 보유하고 있는지 확인하십시오. 그렇지 않으면 데이터베이스 구성 방식에 따라 객체 가져오기 규칙이 실패할 수 있습니다:

$ tsh db connect postgres-db --db-name postgres --db-user teleport-user
psql: error: connection to server at "localhost" (::1), port 50800 failed: Connection refused
	Is the server running on that host and accepting TCP/IP connections?
connection to server at "localhost" (127.0.0.1), port 50800 failed: your Teleport role requires automatic database user provisioning but an attempt to activate database user "teleport-user" failed due to the following error: ERROR: permission denied for table pg_subscription (SQLSTATE 42501)
ERROR: exit status 2

데이터베이스 객체 권한 규칙 실행#

Teleport Database Service는 사용자가 데이터베이스에 연결하도록 허용하기 전에 사용자와 관련된 역할을 확인합니다.

데이터베이스 연결 중에 데이터베이스 객체 권한을 부여하려면 사용자가 다음 특정 기준을 충족하는 역할과 연관되어 있어야 합니다:

  • spec.allow.db_labels가 특정 데이터베이스의 데이터베이스 레이블과 일치해야 합니다.
  • 데이터베이스 사용자 자동 프로비저닝이 활성화되어 있어야 합니다 (spec.options.create_db_user_modeoff로 설정되지 않았거나 spec.options.create_db_user: true인 경우).
  • spec.allow.db_permissions.match의 레이블 키/값 쌍이 특정 데이터베이스 객체의 레이블과 일치해야 합니다.

사용자는 동일한 데이터베이스에 대해 여러 개의 동시 연결을 유지할 수 있습니다. 모든 연결은 동일한 권한을 가져야 하며, 그렇지 않으면 새 연결이 거부됩니다. 마지막으로 활성화된 연결이 종료되면 모든 사용자 권한이 자동으로 취소됩니다.

테이블에 있는 레이블은 적절한 역할과 매칭되어야 합니다. 다음은 ownership_nonprod 규칙에 의해 적용된 dept 레이블을 활용하여 데이터베이스 내 HR 레코드에 대한 읽기 전용 접근 권한을 부여하는 역할의 예시입니다. hr_scratchpad 테이블은 추가로 편집 가능하게 설정됩니다. 반면 dept: sales로 레이블이 지정된 객체는 사용자가 받았을 수 있는 모든 권한을 제거하여 사용할 수 없게 만듭니다. 와일드카드 권한은 spec의 deny 부분(spec.deny.db_permissions)에서만 허용됩니다:

version: v7
kind: role
metadata:
  name: dept_hr_permissions
spec:
  allow:
    db_labels:
      '*': '*'
    db_names:
    - '*'
    db_permissions:
    # default permission: read-only
    - match:
        object_kind: table
        dept: hr
      permissions:
      - SELECT
    # extra permissions for select tables
    - match:
        object_kind: table
        dept: hr
        name: hr_scratchpad
      permissions:
      - SELECT
      - UPDATE
      - DELETE
      - INSERT
  deny:
    db_permissions:
    # explicitly disallow any interaction with `dept: sales` tables.
    - match:
        dept: sales
      permissions:
      - '*'
  options:
    create_db_user_mode: keep

객체 가져오기 규칙 문제 해결#

데이터베이스 객체 가져오기 문제를 진단하려면 Teleport Database Service 로그를 참조하십시오. 이 로그에는 데이터베이스에서 가져온 객체 수, 가져온 객체 수(그 차이는 가져오기 규칙과 일치하지 않은 객체를 의미), 사용자에게 권한이 부여된 객체 수가 표시됩니다:

INFO [DB:SERVIC] Database objects fetched from the database (table:75). db:my-postgres id:b4a33740-1d82-4a8d-b2be-2aa90ae9d2eb total:75 postgres/users.go:212
INFO [DB:SERVIC] Database objects imported (table:75). db:my-postgres err_count:0 id:b4a33740-1d82-4a8d-b2be-2aa90ae9d2eb total:75 postgres/users.go:216
INFO [DB:SERVIC] Calculated database permissions: "INSERT": 75 objects (table:75), "SELECT": 75 objects (table:75), "UPDATE": 75 objects (table:75). db:my-postgres id:b4a33740-1d82-4a8d-b2be-2aa90ae9d2eb user:teleport-user postgres/users.go:223