Vault를 서비스 메시 CA로 사용

이 페이지는 Vault를 Consul 서비스 메시의 인증 기관(CA)으로 사용하는 방법을 설명해요. Vault가 메시의 서비스에 배포되는 인증서를 관리하고 서명할 수 있게 해줘요. Vault CA 공급자는 Vault PKI secrets engine을 사용해 인증서를 생성하고 서명해요.

출처: 문서

본문

이 페이지는 Vault를 Consul 서비스 메시의 인증 기관(CA)으로 사용하는 방법을 설명합니다. 메시의 서비스에 배포되는 인증서를 Vault가 관리하고 서명하도록 Consul을 구성할 수 있습니다. Vault CA 공급자는 Vault PKI secrets engine을 사용해 인증서를 생성하고 서명합니다. 이 페이지는 Vault CA 공급자를 구성하는 방법을 설명합니다.

튜토리얼: Vault를 Consul 서비스 메시 인증 기관으로 구성하는 실습 지침은 Vault as Consul Service Mesh Certification Authority 튜토리얼을 완료하세요.

요구 사항 (Requirements)

Vault 0.10.3 이상

권장 사항 (Recommendations)

Consul이 구성 가능한 CA 공급자로 인증서를 관리하는 방법에 대한 중요한 배경 정보는 Service Mesh Certificate Authority Overview을 참조하세요.
최상의 성능과 복원력을 위해 모든 데이터센터에는 자체 Consul 클러스터와 로컬한 Vault 클러스터가 있어야 합니다.
Consul 데이터센터가 WAN 페더레이션되었고 보조 데이터센터가 Vault Enterprise performance secondaries를 사용한다면, 해당 intermediate_pki_path에 대해 local 마운트를 구성하는 것이 좋습니다.

Vault를 CA로 활성화

Consul이 "vault"를 CA 공급자로 사용하도록 구성하고 필요한 공급자 구성 옵션을 포함하여 Vault를 CA로 활성화할 수 있습니다. Vault는 기존 루트 CA가 서명한 중간 CA로 사용하거나 루트 CA로 사용할 수 있습니다. CA 구성을 서버 에이전트의 구성 파일 또는 /connect/ca/configuration API 엔드포인트에 대한 PUT 요청의 본문에 제공할 수 있습니다. 구성 옵션과 예시 사용 사례에 대한 자세한 내용은 Configuration Reference를 참조하세요.

다음 예시는 기본 구현에 필요한 구성을 보여줍니다.

서비스 메시 CA 구성

/etc/consul.d/config.hcl

# ...
connect {
  enabled = true
  ca_provider = "vault"
  ca_config {
    address = "http://localhost:8200"
    token = "<vault-token-with-necessary-policy>"
    root_pki_path = "connect-root"
    leaf_cert_ttl = "72h"
    private_key_bits = 4096
    private_key_type = "rsa"
    intermediate_cert_ttl = "8760h"
    intermediate_pki_path = "connect-dc1-intermediate"
  }
}

구성 참조 (Configuration Reference)

다음 구성 옵션을 지정할 수 있습니다. 구성 옵션의 이름은 API 호출과 에이전트 구성 파일 사이에서 다를 수 있습니다. 첫 번째 키는 API 호출에 사용할 옵션 이름을 말합니다. 슬래시 뒤의 키는 에이전트 구성 파일의 해당 옵션 이름을 말합니다.

Address / address (string: <required>) - Vault 서버의 주소.
Token / token (string: "") - Vault에 액세스하기 위한 토큰. 이는 쓰기 전용이며 CA 구성을 읽을 때 노출되지 않습니다. 이 토큰은 구성된 PKI 경로에 대해 적절한 권한이 있어야 합니다. Consul 1.8.5 이상에서 토큰에 renewable 플래그가 설정되어 있으면 Consul은 수명의 절반이 경과한 후 주기적으로 임대를 갱신하려 시도합니다.경고: 토큰을 제공하거나 아래의 인증 메서드를 구성해야 합니다.
AuthMethod / auth_method (map: nil) - Vault에 로그인하는 데 사용할 Vault 인증 메서드. 개별 인증 메서드 구성에 대한 자세한 내용은 Vault Auth Methods를 참조하세요. 인증 메서드가 제공되면 Consul은 토큰을 더 이상 갱신할 수 없을 때 Vault에서 새 토큰을 얻습니다.
- Type / type (string: "") - Vault 인증 메서드의 유형. 유효한 옵션은 "approle", "aws", "azure", "gcp", "jwt", "kubernetes"입니다.
- MountPath / mount_path (string: <AuthMethod.Type>) - 인증 메서드의 마운트 경로. 제공되지 않으면 인증 메서드 유형이 마운트 경로로 사용됩니다.
- Params / params (map: nil) - 인증 메서드를 구성할 매개변수. 필요한 구성 매개변수는 사용하는 인증 유형에 따라 다릅니다. 구성 옵션에 대한 자세한 내용은 Vault Agent auto-auth method 문서를 참조하세요: AppRole, AWS, Azure, GCP, JWT, Kubernetes. 인증 관련 필드(예: JWT의 path와 role)만 지원됩니다. 선택적 관리 필드(예: remove_jwt_after_reading)는 지원되지 않습니다.
- 참고 보안 (CVE-2026-2808): Consul 1.22.x부터 인증 메서드 매개변수(path, token_path, role_id_file_path, secret_id_file_path 등)가 참조하는 자격 증명 파일은 특정 허용 디렉터리 내에 있어야 합니다. Consul은 OS 수준 경로 순회 보호를 사용합니다.
RootPKIPath / root_pki_path (string: <required>) - 루트 인증서용 PKI secrets engine의 경로. 기본 데이터센터에 필요합니다. 보조 데이터센터는 이 경로를 사용하지 않습니다.경로가 존재하지 않으면 Consul은 지정된 경로에 RootCertTTL 값을 루트 인증서의 TTL로 하여 새 PKI secrets engine을 마운트합니다. RootCertTTL이 설정되지 않으면 Consul 1.11 이상에서는 기본적으로 87600시간(10년)의 max_lease_ttl이 적용됩니다. Consul 1.11 이전에는 루트 인증서 TTL이 8760시간(1년)으로 설정되었고 구성할 수 없었습니다. 루트 인증서는 지정된 기간이 끝나면 만료됩니다.중간 인증서를 Consul의 기본 CA로 사용하려면 PEM 번들로 Vault의 RootPKIPath를 초기화하세요. 번들의 첫 번째 인증서는 Consul이 기본 CA로 사용할 중간 인증서여야 합니다. 번들의 마지막 인증서는 루트 인증서여야 합니다. 번들은 각 인증서 뒤에 이를 승인한 인증서가 오는 유효한 체인을 포함해야 합니다.
RootPKINamespace / root_pki_namespace (string: <optional>) - RootPKIPath가 있는 절대 네임스페이스. 이 매개변수를 설정하면 RootPKIPath에 대한 Namespace 옵션을 재정의합니다. 1.12.3에서 도입되었습니다.
IntermediatePKIPath / intermediate_pki_path (string: <required>) - 생성된 중간 인증서용 PKI secrets engine의 경로. 이 인증서는 구성된 루트 PKI 경로에 의해 서명됩니다. 이 경로가 존재하지 않으면 Consul이 자동으로 마운트하고 구성하려 시도합니다.WAN 페더레이션이 활성화되면 공통 Vault 클러스터를 공유하는 모든 보조 데이터센터는 고유한 intermediate_pki_path를 지정해야 합니다. Vault 클러스터가 두 개 이상의 Consul 데이터센터에서 사용되지 않는다면 intermediate_pki_path에 고유 값을 지정할 필요가 없습니다. 그러나 운영 및 진단 명확성을 위해 각 데이터센터에 고유한 intermediate_pki_path를 사용하는 것을 여전히 권장합니다.
IntermediatePKINamespace / intermediate_pki_namespace (string: <optional>) - IntermediatePKIPath가 있는 절대 네임스페이스. 이 매개변수를 설정하면 IntermediatePKIPath에 대한 Namespace 옵션을 재정의합니다. 1.12.3에서 도입되었습니다.
CAFile / ca_file (string: "") - Vault 통신에 사용되는 CA 인증서의 선택적 경로를 지정합니다. 지정하지 않으면 OS와 버전에 따라 달라지는 기본 시스템 CA 번들로 폴백됩니다.
CAPath / ca_path (string: "") - Vault 통신에 사용할 CA 인증서가 포함된 폴더의 선택적 경로를 지정합니다. 지정하지 않으면 OS와 버전에 따라 달라지는 기본 시스템 CA 번들로 폴백됩니다.
CertFile / cert_file (string: "") - Vault 통신에 사용되는 인증서의 경로를 지정합니다. 설정되면 key_file도 설정해야 합니다.
KeyFile / key_file (string: "") - Vault 통신에 사용되는 개인 키의 경로를 지정합니다. 설정되면 cert_file도 설정해야 합니다.
TLSServerName / tls_server_name (string: "") - TLS로 Vault에 연결할 때 SNI 호스트를 설정하는 데 사용되는 선택적 문자열을 지정합니다.
TLSSkipVerify / tls_skip_verify (bool: false) - SSL 피어 검증을 강제해야 하는지 지정합니다.
Namespace / namespace (string: <optional>) - Token과 PKI 인증서가 속한 Vault Namespace. Vault Namespace는 Vault Enterprise 기능입니다. Consul 1.11.0에 추가되었습니다.

공통 CA 구성 옵션

다음 구성 옵션은 모든 CA 공급자가 지원합니다.

CSRMaxConcurrent / csr_max_concurrent (int: 0) - 동시에 처리할 수 있는 Certificate Signing Request 수에 제한을 설정합니다. 기본값은 0(비활성화)입니다. 이는 서버가 인증서 서명 작업에 사용할 수 있는 CPU 코어 수를 제한하려 할 때 유용합니다. 예를 들어 8코어 서버에서 이 값을 1로 설정하면 인증서를 생성하거나 교체할 때 하나 이상의 CPU 코어가 소비되지 않도록 보장합니다. 회전을 인위적으로 늦추지 않고 CSR 리소스를 제한하는 것을 추론하기 더 간단하므로 CPU 코어 수를 제한하려면 csr_max_per_second 대신 이 값을 설정하는 것이 좋습니다. 1.4.1에서 추가되었습니다.
CSRMaxPerSecond / csr_max_per_second (float: 50) - 서버가 수락할 Certificate Signing Request(CSR)의 최대 수에 대한 속도 제한을 설정합니다. 이는 CA 교체가 서버에서 무제한 CPU 사용을 일으키는 것을 방지하는 데 사용됩니다. 기본값은 보수적인 50입니다. 2017 MacBook은 하나의 CPU 코어의 약 40%만 사용하여 초당 약 100개를 처리할 수 있습니다. 그러나 ~1500 서비스 인스턴스까지의 배포에는 회전 시간이 영향을 받기 전까지 충분합니다. 더 큰 배포의 경우 예상 서버 인스턴스 수와 서버 리소스를 기반으로 이 값을 높이거나, 서버에 CPU 코어가 두 개 이상인 경우 csr_max_concurrent를 대신 사용하는 것이 좋습니다. 이 값을 0으로 설정하면 속도 제한이 비활성화됩니다. 1.4.1에서 추가되었습니다.
LeafCertTTL / leaf_cert_ttl (duration: "72h") - 서비스에 대해 발급된 리프 인증서의 임대 기간 상한. 대부분의 경우 이 한도에 도달하기 전에 프록시가 새 리프 인증서를 요청합니다. 이는 서버 중단(리더 없음)이 네트워크 연결이 거부되기 시작하기 전까지 지속될 수 있는 유효 제한이기도 합니다. 기본값은 72h입니다. 이 값은 1시간보다 낮거나 1년보다 높을 수 없습니다.
- 이 값은 클러스터에서 이전 루트 인증서를 교체할 때도 사용됩니다. 루트 인증서가 현재 leaf_cert_ttl의 두 배보다 오랫동안 비활성(교체됨) 상태였으면 신뢰 목록에서 제거됩니다.
RootCertTTL / root_cert_ttl (duration: "87600h") - 루트 인증서의 수명(TTL). 기본값은 87600h인 10년입니다. 제공된 경우 이 값은 중간 인증서 TTL보다 높아야 합니다.이 설정은 모든 Consul CA 공급자에 적용됩니다.Vault 공급자의 경우 이 값은 백엔드가 처음에 초기화되지 않은 경우에만 사용됩니다.
IntermediateCertTTL / intermediate_cert_ttl (duration: "8760h") - 기본 데이터센터의 루트 인증서에 의해 서명된 중간 인증서의 수명(TTL). 이 필드는 기본 데이터센터에서만 유효합니다. 기본값은 8760h인 1년입니다.이 설정은 모든 Consul CA 공급자에 적용됩니다.Vault 공급자의 경우 이 값은 백엔드가 처음에 초기화되지 않은 경우에만 사용됩니다.
PrivateKeyType / private_key_type (string: "ec") - 이 CA에 대해 생성할 키 유형. 공급자가 새 키를 생성할 때만 사용됩니다. Consul 공급자에 대해 private_key가 설정되거나 Vault에 기존 루트 또는 중간 PKI 경로가 주어지면 무시됩니다. 현재 지원되는 옵션은 ec 또는 rsa입니다. 기본값은 ec입니다. 데이터센터의 모든 서버가 CA에 대해 동일한 구성을 갖는 것이 필요합니다. 내장 CA와 Vault 공급자는 모두 혼합 CA 키 유형을 허용하지만, 다른 데이터센터의 서버가 같은 키 유형과 크기를 사용하는 것이 좋습니다. 일부 CA 공급자(현재 Vault)는 다른 키 유형으로 새 CA 인증서를 교차 서명하는 것을 허용하지 않습니다. 이는 RSA 키 Vault CA에서 어떤 공급자의 EC 키 CA로 마이그레이션하는 경우 교차 서명 없이 진행해야 할 수 있음을 의미하며, 새 인증서 롤아웃 중 워크로드에 일시적인 연결 문제가 발생할 수 있습니다. 프로덕션 밖에서 이를 테스트하여 영향을 이해하는 것을 매우 권장하며, 가능하면 동일한 키 유형을 고수할 것을 제안합니다.참고: 이는 공급자가 생성한 CA 키에만 영향을 줍니다. 리프 인증서 키는 CA 구성과 무관하게 항상 EC 256입니다.
PrivateKeyBits / private_key_bits (string: "") - 이 CA에 대해 생성할 키의 길이. 공급자가 새 키를 생성할 때만 사용됩니다. Consul 공급자에 대해 private_key가 설정되거나 Vault에 기존 루트 또는 중간 PKI 경로가 주어지면 무시됩니다.현재 지원되는 값은 다음과 같습니다.
- private_key_type = ec (기본값): 같은 이름의 NIST P-* 곡선에 해당하는 224, 256, 384, 521.
- private_key_type = rsa: 2048, 4096

루트 및 중간 PKI 경로

Vault CA 공급자는 Consul 서비스 메시 인증서를 관리하기 위해 별도로 구성된 두 개의 PKI secrets engine을 사용합니다.

RootPKIPath는 루트 인증서용 PKI 엔진입니다. Consul은 이 루트 인증서를 사용해 중간 인증서에 서명합니다. Consul은 루트 PKI 경로 내의 어떤 데이터도 쓰거나 수정하려 시도하지 않습니다.

IntermediatePKIPath는 루트 인증서로 서명된 중간을 저장하는 데 사용되는 PKI 엔진입니다. 중간이 모든 리프 인증서에 서명하며, Consul은 자동 교체를 위해 주기적으로 새 중간을 생성할 수 있습니다. 따라서 Consul은 이 경로에 대한 쓰기 액세스가 필요합니다.

각 경로에 대해 경로가 존재하지 않으면 Consul은 해당 경로에 PKI secrets engine을 마운트하고 초기화하려 시도합니다. 이 작업이 성공하려면 제공된 Vault 토큰이 필요한 Vault 권한을 가져야 합니다. 경로가 이미 존재하면 Consul은 해당 경로의 PKI secrets engine을 구성된 대로 사용합니다.

Vault ACL 정책 구성

Vault CA 공급자는 마운트 구성을 Vault에서 제어할지 아니면 그 책임을 Consul에 위임할지에 따라 특정 Vault 권한 집합이 있는 Vault 토큰이 필요합니다.

Vault 관리 PKI 경로를 사용하면 다음 이점을 얻습니다.

RootPKIPath에서 중간 인증서로 PKI secrets engine을 인스턴스화하여 Consul 외부의 루트 CA를 사용할 수 있게 함
PKI 마운트 생성과 RootPKIPath 마운트 구성에 대한 전체 제어 유지

그렇지 않으면 Consul 관리 PKI 경로를 사용해 Consul이 PKI 관리를 완전히 자동화하도록 하세요.

다음 섹션은 두 옵션에 필요한 Vault 정책을 설명합니다. 정책 스니펫은 RootPKIPath와 IntermediatePKIPath에 대해 자리 표시자 값을 사용합니다. CA 공급자 구성의 경로 값과 일치하도록 바꾸세요.

Vault 관리 PKI 경로에 대한 정책 정의

Vault 관리 PKI 경로를 사용하려면 먼저 RootPKIPath와 IntermediatePKIPath에서 PKI secrets engine을 인스턴스화하고 구성해야 합니다.

그런 다음 다음 Vault ACL 정책을 CA 공급자의 Vault 토큰 또는 인증 메서드에 연결하세요.

Consul이 두 PKI 마운트를 읽고 중간 PKI 마운트 구성을 관리할 수 있게 합니다. vault-managed-pki-policy.hcl

path "/sys/mounts/<root_pki_path>" {
  capabilities = [ "read" ]
}

path "/sys/mounts/<intermediate_pki_path>" {
  capabilities = [ "read" ]
}

path "/sys/mounts/<intermediate_pki_path>/tune" {
  capabilities = [ "update" ]
}

Consul이 루트 PKI 엔진에 대해 읽기 전용 액세스를 갖고 필요에 따라 중간 CA를 자동으로 교체하며 중간 PKI 엔진을 완전히 사용할 수 있게 합니다. vault-managed-pki-policy.hcl

path "/<root_pki_path>/" {
  capabilities = [ "read" ]
}

path "/<root_pki_path>/root/sign-intermediate" {
  capabilities = [ "update" ]
}

path "/<intermediate_pki_path>/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

토큰이 갱신 가능하면 Consul이 Vault 토큰을 갱신할 수 있게 합니다. 이 규칙은 토큰이 CA 공급자 구성에 직접 제공되든 인증 메서드에 제시되든 갱신할 수 있게 합니다. vault-managed-pki-policy.hcl
```
path "auth/token/renew-self" {
  capabilities = [ "update" ]
}

path "auth/token/lookup-self" {
  capabilities = [ "read" ]
}
```

Consul 관리 PKI 경로에 대한 정책 정의

Consul 관리 PKI 경로를 사용하려면 RootPKIPath와 IntermediatePKIPath에 PKI secrets engine이 마운트되지 않았는지 확인하세요.

그런 다음 다음 Vault ACL 정책을 CA 공급자의 Vault 토큰 또는 인증 메서드에 연결하세요.

Consul이 두 PKI 엔진을 만들고 관리할 수 있게 합니다. consul-managed-pki-policy.hcl

path "/sys/mounts/<root_pki_path>" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

path "/sys/mounts/<intermediate_pki_path>" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

path "/sys/mounts/<intermediate_pki_path>/tune" {
  capabilities = [ "update" ]
}

Consul이 두 PKI 엔진을 완전히 사용할 수 있게 합니다. consul-managed-pki-policy.hcl

path "/<root_pki_path>/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

path "/<intermediate_pki_path>/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

토큰이 갱신 가능하면 Consul이 Vault 토큰을 갱신할 수 있게 합니다. 이 규칙은 토큰이 CA 공급자 구성에 직접 제공되든 인증 메서드에 제시되든 갱신할 수 있게 합니다. consul-managed-pki-policy.hcl
```
path "auth/token/renew-self" {
  capabilities = [ "update" ]
}

path "auth/token/lookup-self" {
  capabilities = [ "read" ]
}
```

민감한 작업을 위한 추가 Vault ACL 정책

다음 CA 공급자 구성 변경을 수행하는 동안 추가 Vault 권한이 필요합니다.

공급자를 Vault에서 다른 공급자(예: Consul의 내장 공급자)로 변경
RootPKIPath 변경

이러한 구성 수정은 매우 권한 있는 루트 교차 서명 작업을 요구하는 루트 CA 변경을 트리거합니다. 그 작업이 성공하려면 CA 공급자의 Vault 토큰 또는 인증 메서드가 다음 규칙을 포함해야 합니다.

temporary-sensitive-operation-pki-policy.hcl

path "<root_pki_path>/root/sign-self-issued" {
  capabilities = [ "sudo", "update" ]
}

이러한 CA 공급자 구성 변경을 수행할 때 권한 있는 Vault 토큰이 사용되는 시간을 최소화하기 위해 다음 과정을 사용하는 것이 좋습니다.

root/sign-self-issued 권한과 현재 Consul 또는 Vault 관리 PKI 경로에 대한 표준 권한을 모두 포함하는 새 Vault 토큰을 만듭니다.
CA 공급자 구성을 그 새 Vault 토큰을 사용하도록 수정합니다.
매우 권한 있는 루트 교차 서명 작업을 트리거하는 CA 공급자 구성 변경을 수행합니다. 구성 변경이 Vault를 공급자로 유지하면서 RootPKIPath를 수정한다면, 구성 변경은 새 Consul 또는 Vault 관리 PKI 경로에 대한 표준 권한을 가진 Vault 토큰 또는 인증 메서드를 포함해야 합니다.

Vault를 서비스 메시 CA로 사용