이 가이드는 Teleport Terraform 시작 가이드의 두 번째 부분입니다. Terraform 시작 가이드의 범위와 목적에 대한 개요를 읽어보세요.

이 시리즈의 파트 1에서는 Terraform을 사용하여 Teleport 에이전트를 배포하여 인프라스트럭처 자원을 Teleport 클러스터에 등록하는 방법을 보여주었습니다. 에이전트를 구성할 때 환경에 따라 레이블을 지정했으며, 일부는 dev 에 속하고 다른 일부는 prod 에 속합니다.

이 가이드에서는 최소 권한 원칙을 구현하기 위해 dev 및 prod 레이블로 리소스에 대한 액세스를 관리할 수 있도록 Teleport 클러스터를 구성합니다.

작동 방식

이 가이드에서는 다음을 생성하는 방법을 보여줍니다:

• prod 리소스에 액세스할 수 있는 역할.
• dev 리소스에 액세스하고 prod 리소스에 대한 액세스를 요청할 수 있는 역할.
• 사용자가 귀하의 조직의 ID 공급자에 로그인하고 자동으로 dev 리소스에 액세스할 수 있도록 하는 인증 커넥터.

이 설정에서는 prod 리소스에 접근하는 유일한 방법은 액세스 요청을 통해 이루어지며, 이는 공격자가 손상시킬 수 있는 prod 리소스에 대한 상시 자격 증명이 없음을 의미합니다.

전제 조건

이 가이드는 파트 1: Terraform으로 인프라 등록을 완료했다고 가정합니다.

• 실행 중인 Teleport 클러스터 버전 16.2.0 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.

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

  tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하십시오.

• dev 및 prod 레이블이 포함된 Teleport에 등록된 리소스. 이 리소스의 등록 방법은 파트 1에서 설명합니다.
• OIDC 또는 SAML을 지원하는 ID 공급자. 다음 중 하나의 능력이 있어야 합니다:
  • 귀하의 조직에서 SAML 속성 또는 OIDC 클레임을 수정할 수 있는 능력.
  • 두 가지 액세스 수준에 매핑할 기존 사용자 그룹: dev 리소스에 연결할 수 있는 능력과 prod 액세스를 위한 액세스 요청을 검토할 수 있는 능력.

• Terraform v1.0.0 이상.
• 연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:

  tsh login --proxy=teleport.example.com --user=email@example.com
  tctl status
  클러스터  teleport.example.com
  버전  17.0.0-dev
  CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

  클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
  자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.
• 문제 해결을 돕기 위해, 이 가이드의 설정 단계를 editor 및 auditor 역할이 설정된 로컬 사용자로 완료하는 것을 추천합니다. 운영 환경에서는 덜 권한이 있는 사용자를 통해 이 가이드의 내용을 적용할 수 있습니다.

1/4단계. Terraform 모듈 가져오기

이 단계에서는 Teleport RBAC를 관리하는 방법을 보여주는 Terraform 모듈을 다운로드합니다. 이 모듈은 Teleport Terraform 리소스가 함께 작동하여 Teleport 역할 및 인증 커넥터를 관리하는 방법을 보여주는 최소한의 예입니다.

이 가이드를 마치고 설정에 익숙해진 후에는 Terraform 구성을 수정하여 운영 환경에 맞출 수 있습니다.

1. 루트 Terraform 모듈에 대해 파일을 정리한 디렉터리로 이동합니다.

2. Teleport 코드 리포지토리를 가져오고 이 프로젝트의 예제 Terraform 구성을 현재 작업 디렉터리로 복사합니다.

   사용자가 귀하의 조직의 ID 공급자(IdP)를 통해 Teleport에 인증하도록 활성화할 것이므로 모듈은 조직에서 OIDC 또는 SAML을 사용하여 서비스와 소통하는지에 따라 다릅니다:

git clone --depth=1 https://github.com/gravitational/teleport teleport-clone
cp -R teleport-clone/examples/terraform-starter/env_role env_role
cp -R teleport-clone/examples/terraform-starter/oidc oidc
rm -rf teleport-clone

git clone --depth=1 https://github.com/gravitational/teleport teleport-clone
cp -R teleport-clone/examples/terraform-starter/env_role env_role
cp -R teleport-clone/examples/terraform-starter/saml saml
rm -rf teleport-clone

프로젝트 디렉터리에는 두 개의 새로운 모듈이 포함됩니다:

1. 다음 module 블록을 포함하는 rbac.tf 라는 파일을 생성합니다:

module "oidc" {
  source               = "./oidc"
  oidc_claims_to_roles = []
  oidc_client_id       = ""
  oidc_connector_name  = "OIDC로 로그인"
  oidc_redirect_url    = ""
  oidc_secret          = ""
  teleport_domain      = ""
}

module "prod_role" {
  source        = "./env_role"
  env_label     = "prod"
  principals    = {}
  request_roles = []
}

module "dev_role" {
  source        = "./env_role"
  env_label     = "dev"
  principals    = {}
  request_roles = [module.prod_role.role_name]
}

module "saml" {
  source                   = "./saml"
  saml_connector_name      = "SAML로 로그인"
  saml_attributes_to_roles = []
  saml_acs                 = ""
  saml_entity_descriptor   = ""
  teleport_domain          = ""
}

module "prod_role" {
  source        = "./env_role"
  env_label     = "prod"
  principals    = {}
  request_roles = []
}

module "dev_role" {
  source        = "./env_role"
  env_label     = "dev"
  principals    = {}
  request_roles = [module.prod_role.role_name]
}

다음으로, 두 개의 자식 모듈을 구성하는 방법을 보여주고 이들이 적용하는 Terraform 리소스를 안내하겠습니다.

2/4단계. 역할 주체 구성

1단계에서 선언한 prod_role 및 dev_role 모듈이 함께 작동하여 세 가지 Teleport 역할을 생성합니다:

Teleport 사용자가 인프라의 리소스에 연결할 때, 그들은 운영 체제 로그인이나 Kubernetes 사용자와 같은 주체를 가정하여 해당 리소스와 상호작용합니다. 이 단계에서는 prod_role 및 dev_role 모듈을 구성하여 인프라의 주체에 대한 액세스를 부여합니다.

rbac.tf 에서 prod_role 및 dev_role 블록을 편집하여 principals 필드에 다음 예제와 유사한 매핑을 포함시킵니다. 아래 예제 아래에 있는 키 목록을 사용하여 주체를 구성하십시오.

module "prod_role" {
  principals = {
    KEY = "value"
  }
  // ...
}

// ...

예를 들어, 다음 구성은 dev_access 역할을 가진 사용자가 Linux 호스트에서 dev 로그인 및 Kubernetes에서 developers 그룹을 가장할 수 있도록 합니다. prod 사용자는 더 많은 권한을 가지며, root 로그인 및 system:masters Kubernetes 그룹을 가장할 수 있습니다:

module "dev_role" {
  principals = {
    logins            = ["dev"]
    kubernetes_groups = ["developers"]
  }
  // ...
}

module "prod_role" {
  principals = {
    logins            = ["root"]
    kubernetes_groups = ["system:masters"]
  }
  // ...
}

3/4단계. [선택 사항] 싱글 사인온 커넥터 구성

이 단계에서는 Terraform 모듈을 구성하여 조직의 IdP를 통해 인증을 활성화합니다. 1단계에서 선언한 saml 또는 oidc 모듈을 안내에 따라 구성하십시오.

1. Teleport 클러스터를 IdP에 의존하는 당사자로 등록합니다. 지침은 IdP에 따라 다릅니다.

   다음 가이드는 SAML 또는 OIDC 인증 커넥터를 지원하도록 IdP를 설정하는 방법을 보여줍니다. 연결된 섹션만 읽으십시오, 이 가이드는 tctl 을 사용하여 인증 커넥터를 관리하는 것으로 가정하고 있기 때문입니다.

   • AD FS
   • GitLab
   • Google Workspace
   • OneLogin
   • Azure AD
   • Okta

2. 리디렉션 URL(ODA의 경우) 또는 주장 소비 서비스(SAML의 경우)를 구성합니다:

1. Teleport를 의존하는 당사자로 등록한 후, 아이덴티티 공급자가 인증 커넥터를 구성하는 데 사용할 정보를 출력합니다. 공급자 유형에 따라 정보를 입력합니다:

1. teleport_domain 을 Teleport 프록시 서비스의 도메인 이름으로 할당하고, 스킴이나 경로 없이 예를 들어 example.teleport.sh 와 같이 설정합니다. 자식 모듈은 이를 사용하여 로컬 사용자에 대한 WebAuthn을 구성합니다. 이렇게 하면 싱글 사인온 인증 커넥터를 문제 해결해야 할 때 로컬 사용자로 인증할 수 있습니다.

2. 인증 커넥터의 역할 매핑을 구성합니다. 사용자가 조직의 IdP를 통해 Teleport에 인증할 때, Teleport는 커넥터의 역할 매핑 구성에 기반하여 사용자에게 역할을 할당합니다:

     oidc_claims_to_roles = [
       {
         claim = "group"
         value = "developers"
         roles = [
           module.dev_role.role_name
         ]
       },
       {
         claim = "group"
         value = "admins"
         roles = module.dev_role.reviewer_role_names
       }
     ]

     saml_attributes_to_roles = [
       {
         name  = "group"
         value = "developers"
         roles = [
           module.dev_role.role_name
         ]
       },
       {
         name  = "group"
         value = "admins"
         roles = module.dev_role.reviewer_role_names
       }
     ]

4/4단계. 변경사항 적용 및 검증

이 단계에서는 Terraform 구성을 적용하기 위해 Teleport 봇을 생성합니다. 봇은 1시간 동안 존재하며, TF 제공자가 지원하는 모든 리소스를 수정할 수 있는 기본 terraform-provider 역할이 부여됩니다.

1. Terraform 프로젝트 디렉토리로 이동하고 다음 명령을 실행합니다.
   eval 명령은 셸의 환경 변수를 Teleport Terraform 제공자에 대한 자격 증명으로 할당합니다:

   eval "$(tctl terraform env)"
   🔑 MFA 필요 여부를 감지하는 중입니다.이는 관리자 수준의 작업이며 완료를 위해 MFA가 필요합니다.보안 키를 눌러주세요.보안 키가 감지되었습니다.⚙️ 임시 봇 "tctl-terraform-env-82ab1a2e"와 해당 토큰을 생성하는 중입니다.🤖 임시 봇을 사용하여 인증서를 얻는 중입니다.🚀 인증서를 얻었습니다. 이제 이 터미널에서 1시간 0분 0초 동안 Terraform을 사용할 수 있습니다.

2. 귀하의 클라우드 제공자 자격 증명이 귀하의 조직에 대한 표준 방식으로 Terraform에 사용 가능하도록 하십시오.

3. Terraform 구성을 적용합니다:

   terraform init
   terraform apply

4. 브라우저에서 Teleport 웹 UI를 열고, groups 속성이 인증 커넥터에서 역할에 매핑된 값으로 할당된 IdP의 사용자로 Teleport에 로그인합니다. 사용자에게는 dev_access 역할이 있어야 합니다.

   인증 커넥터를 사용하여 로그인할 때 오류가 발생하면, Teleport 감사 로그를 볼 수 있는 권한이 있는 로컬 사용자로 로그인하십시오. 이는 미리 설정된 auditor 역할에서 사용 가능합니다. "SSO 로그인" 유형과 관련된 이벤트에서 오류 메시지를 확인하십시오.

5. 웹 UI를 통해 prod_access 역할에 대한 액세스를 요청합니다. "액세스 요청" 탭을 방문하고 "새 요청"을 클릭합니다.

6. 웹 UI에서 로그아웃하고, prod_access 역할에 매핑된 그룹의 사용자로 로그인합니다. "액세스 요청" 탭에서 생성한 액세스 요청을 확인하고 해결할 수 있어야 합니다.

추가 읽기: 모듈 작동 방식

이 섹션에서는 env_role , saml , oidc 하위 모듈이 관리하는 리소스를 설명합니다. 이 설정을 복사하고 사용자 정의하여 설정을 세분화하고 환경을 위해 가장 재사용 가능한 인터페이스를 선택할 것을 권장합니다.

env_access 역할

env_role 하위 모듈은 env 레이블이 있는 Teleport 보호 리소스에 접근할 수 있는 Teleport 역할을 생성합니다:

resource "teleport_role" "env_access" {
  version = "v7"
  metadata = {
    name        = "${var.env_label}_access"
    description = "Can access infrastructure with label ${var.env_label}"
    labels = {
      env = var.env_label
    }
  }

  spec = {
    allow = {
      aws_role_arns          = lookup(var.principals, "aws_role_arns", [])
      azure_identities       = lookup(var.principals, "azure_identities", [])
      db_names               = lookup(var.principals, "db_names", [])
      db_users               = lookup(var.principals, "db_users", [])
      gcp_service_accounts   = lookup(var.principals, "gcp_service_accounts", [])
      kubernetes_groups      = lookup(var.principals, "kubernetes_groups", [])
      kubernetes_users       = lookup(var.principals, "kubernetes_users", [])
      logins                 = lookup(var.principals, "logins", [])
      windows_desktop_logins = lookup(var.principals, "windows_desktop_logins", [])

      request = {
        roles           = var.request_roles
        search_as_roles = var.request_roles
        thresholds = [{
          approve = 1
          deny    = 1
          filter  = "!equals(request.reason, \"\")"
        }]
      }

      app_labels = {
        env = [var.env_label]
      }

      db_labels = {
        env = [var.env_label]
      }

      node_labels = {
        env = [var.env_label]
      }

      kubernetes_labels = {
        env = [var.env_label]
      }

      windows_desktop_labels = {
        env = [var.env_label]
      }
    }
  }
}

output "role_name" {
  value = teleport_role.env_access.metadata.name
}

이 역할은 사용자 구성된 env 레이블이 있는 애플리케이션, 데이터베이스, Linux 서버, Kubernetes 클러스터 및 Windows 데스크톱에 접근할 수 있는 allow 규칙을 하드코딩합니다.

귀하의 인프라에서 사용 가능한 주체를 예측할 수 없으므로, 이 역할은 사용자가 구성할 수 있도록 aws_role_arns , logins , 및 기타 주체 관련 역할 속성을 남겨둡니다.

역할은 또한 사용자가 request_roles 입력 변수에 구성된 역할에 대한 접근 요청을 할 수 있도록 하는 allow 규칙을 구성합니다.

output 은 역할의 이름을 출력하여 이 역할과 인증 커넥터 간의 종속성 관계를 생성할 수 있도록 합니다.

env_access_reviewer 역할

env_access 역할의 var.request_roles 가 비어 있지 않은 경우, env_role 모듈은 이러한 역할을 검토할 수 있는 역할을 생성합니다. 이는 권한을 더 조합 가능하게 만들기 위한 별도의 역할입니다:

locals {
  can_review_roles = join(", ", var.request_roles)
}

resource "teleport_role" "env_access_reviewer" {
  version = "v7"
  count   = length(var.request_roles) > 0 ? 1 : 0
  metadata = {
    name        = "${local.can_review_roles}_reviewer"
    description = "Can review Access Requests for: ${local.can_review_roles}"
  }

  spec = {
    allow = {
      review_requests = {
        roles = var.request_roles
      }
    }
  }
}

output "reviewer_role_names" {
  value = teleport_role.env_access_reviewer[*].metadata.name
}

env_access 역할과 마찬가지로, 인증 커넥터와의 종속성 관계를 생성하기 위해 env_access_reviewer 역할의 이름을 출력하는 출력 항목이 있습니다.

인증 커넥터 구성

인증 커넥터 리소스는 최소한입니다. Teleport OIDC와 SAML 메시지를 보내고 받을 수 있도록 필요한 속성을 제공하는 것을 넘어, 커넥터는 사용자 제공 값에 기반한 역할 매핑을 구성합니다:

resource "teleport_oidc_connector" "main" {
  version = "v3"
  metadata = {
    name = var.oidc_connector_name
  }

  spec = {
    client_id       = var.oidc_client_id
    client_secret   = var.oidc_secret
    claims_to_roles = var.oidc_claims_to_roles
    redirect_url    = [var.oidc_redirect_url]
  }
}

resource "teleport_saml_connector" "main" {
  version = "v2"
  metadata = {
    name = var.saml_connector_name
  }

  spec = {
    attributes_to_roles = var.saml_attributes_to_roles

    acs               = var.saml_acs
    entity_descriptor = var.saml_entity_descriptor
  }
}

역할 매핑 입력이 복합 데이터 유형이므로, oidc 및 saml 자식 모듈에 대한 입력 변수를 선언할 때 복잡한 유형 정의를 추가합니다:

variable "teleport_domain" {
  type        = string
  description = "Domain name of your Teleport cluster (to configure WebAuthn)"
}

variable "oidc_claims_to_roles" {
  type = list(object({
    claim = string
    roles = list(string)
    value = string
  }))
  description = "Mappings of OIDC claims to lists of Teleport role names"
}

variable "oidc_client_id" {
  type        = string
  description = "The OIDC identity provider's client iD"
}

variable "oidc_connector_name" {
  type        = string
  description = "Name of the Teleport OIDC connector resource"
}

variable "oidc_redirect_url" {
  type        = string
  description = "Redirect URL for the OIDC provider."
}

variable "oidc_secret" {
  type        = string
  description = "Secret for configuring the Teleport OIDC connector. Available from your identity provider."
}

variable "teleport_domain" {
  type        = string
  description = "Domain name of your Teleport cluster (to configure WebAuthn)"
}

variable "saml_connector_name" {
  type        = string
  description = "Name for the SAML authentication connector created by this module"
}

variable "saml_attributes_to_roles" {
  type = list(object({
    name  = string
    roles = list(string)
    value = string
  }))
  description = "Mappings of SAML attributes to lists of Teleport role names"
}

variable "saml_acs" {
  type        = string
  description = "URL (scheme, domain, port, and path) for the SAML assertion consumer service"
}

variable "saml_entity_descriptor" {
  type        = string
  description = "SAML entity descriptor"
}

각 인증 커넥터에 대해, 커넥터를 활성화하는 클러스터 인증 기본 설정을 선언합니다. 클러스터 인증 기본 설정은 단일 사인온 공급자를 문제 해결해야 할 경우, 보안 백업으로 WebAuthn을 통한 로컬 사용자 로그인을 가능하게 만듭니다.

resource "teleport_auth_preference" "main" {
  version = "v2"
  metadata = {
    description = "Require authentication via the ${var.oidc_connector_name} connector"
  }

  spec = {
    connector_name   = teleport_oidc_connector.main.metadata.name
    type             = "oidc"
    allow_local_auth = true
    second_factor    = "webauthn"
    webauthn = {
      rp_id = var.teleport_domain
    }
  }
}

resource "teleport_auth_preference" "main" {
  version = "v2"
  metadata = {
    description = "Require authentication via the ${var.saml_connector_name} connector"
  }

  spec = {
    connector_name   = teleport_saml_connector.main.metadata.name
    type             = "saml"
    allow_local_auth = true
    second_factor    = "webauthn"
    webauthn = {
      rp_id = var.teleport_domain
    }
  }
}

다음 단계

Terraform 데모 클러스터에서 RBAC 구성을 완료했으므로, 포괄적인 Terraform 제공자 참조를 읽어 보며 설정을 세밀하게 조정하십시오.