내장 CA

내장 CA (Built-in CA)

Consul과 함께 제공되어 서비스 메시를 쉽게 활성화할 수 있게 해주는 내장 CA 시스템을 설명하는 문서예요. 내장 CA는 루트 인증서와 개인 키를 Consul 서버에 생성하고 저장해요.

출처: 문서

본문

Consul은 서비스 메시를 바로 쉽게 활성화할 수 있도록 내장 CA 시스템을 제공합니다. 내장 CA는 루트 인증서와 개인 키를 생성해 Consul 서버에 저장합니다. 필요하면 사용자 정의 인증서와 개인 키로 구성할 수도 있습니다.

서비스 메시가 활성화되고 CA 프로바이더가 지정되지 않으면 내장 CA가 기본 프로바이더로 사용됩니다. 이 프로바이더는 언제든지 업데이트 및 회전하여 새 프로바이더로 마이그레이션할 수 있습니다.

참고 이 페이지는 내장 CA 프로바이더의 세부 사항을 문서화합니다. Consul이 구성 가능한 CA 프로바이더로 인증서를 어떻게 관리하는지 이해하려면 먼저 인증서 관리 개요 페이지를 읽어보세요.

구성 (Configuration)

내장 CA 프로바이더에는 필수 구성이 없습니다. 서비스 메시를 활성화하는 것만으로 내장 CA 프로바이더가 구성되고 루트 인증서와 개인 키가 자동으로 생성됩니다:

# ...
connect {
  enabled = true
}

구성 옵션은 아래에 나열됩니다.

참고 첫 번째 키는 API 호출에 사용되는 값이고, 두 번째 키(슬래시 뒤)는 에이전트의 구성 파일에 구성을 추가할 때 사용합니다.

PrivateKey / private_key (string: "") - 서명 작업을 위한 PEM 인코딩 개인 키입니다. 수동으로 지정하면 루트 인증서에 사용된 개인 키와 일치해야 합니다. 비어 있으면 개인 키가 자동으로 생성됩니다.
RootCert / root_cert (string: "") - 사용할 PEM 인코딩 루트 인증서입니다. 비어 있으면 지정된 개인 키를 사용해 루트 인증서가 자동으로 생성됩니다. 지정하면 인증서는 유효한 SPIFFE SVID 서명 인증서여야 하며 SAN의 URI는 부트스트랩 시 ".consul" TLD로 생성된 클러스터 식별자와 일치해야 합니다. 클러스터 식별자는 CA List Roots 엔드포인트를 사용해 찾을 수 있습니다.

공통 CA 구성 옵션 (Common CA Config Options)

다음 구성 옵션은 모든 CA 프로바이더에서 지원됩니다:

CSRMaxConcurrent / csr_max_concurrent (int: 0) - 동시에 처리할 수 있는 인증서 서명 요청(CSR) 수에 대한 제한을 설정합니다. 기본값은 0(비활성화)입니다. 인증서 서명 작업에 서버가 사용할 수 있는 CPU 코어 수를 제한하려고 할 때 유용합니다. 예를 들어 8코어 서버에서 1로 설정하면 인증서를 생성하거나 회전할 때 하나 이상의 CPU 코어가 소비되지 않도록 보장합니다. csr_max_per_second 대신 이 설정을 사용하는 것이 권장됩니다. 1.4.1에서 추가되었습니다.
CSRMaxPerSecond / csr_max_per_second (float: 50) - 서버가 수락할 최대 인증서 서명 요청(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년입니다. 이 값은 제공되면 중간(intermediate) 인증서 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에 생성할 키 길이입니다. 프로바이더가 새 키를 생성할 때만 사용됩니다.
- private_key_type = ec(기본값): 224, 256, 384, 521 — 같은 이름의 NIST P-* 곡선에 해당.
- private_key_type = rsa: 2048, 4096

사용자 정의 개인 키와 루트 인증서 지정 (Specifying a Custom Private Key and Root Certificate)

기본적으로 루트 인증서와 개인 키는 클러스터 부트스트랩 중에 자동 생성됩니다. Consul CA 프로바이더가 특정 개인 키와 루트 인증서를 사용하도록 구성할 수 있습니다. 이는 현재 Consul과 직접 통합되지 않는 외부 PKI 시스템이 있을 때 특히 유용합니다.

현재 CA 구성을 보려면 Get CA Configuration 엔드포인트를 사용하세요:

$ curl localhost:8500/v1/connect/ca/configuration
{
    "Provider": "consul",
    "Config": {
        "LeafCertTTL": "72h",
        "IntermediateCertTTL": "8760h"
    },
    "CreateIndex": 5,
    "ModifyIndex": 5
}

이것은 서비스 메시가 활성화될 때 아무것도 명시적으로 설정하지 않은 경우의 기본 서비스 메시 CA 구성입니다. PrivateKey와 RootCert 필드가 설정되지 않았으므로 생성되었습니다.

Consul CA가 사용자 정의 개인 키와 루트 인증서를 사용하게 하는 방법은 두 가지가 있습니다: Agent 구성의 ca_config 섹션(클러스터 초기 부트스트랩 중에만 사용 가능) 또는 Update CA Configuration 엔드포인트를 통하는 것입니다.

현재 Consul은 루트 인증서가 유효한 SPIFFE SVID 서명 인증서여야 하고 SAN에 인코딩된 URI가 부트스트랩 시 ".consul" TLD로 생성된 클러스터 식별자여야 한다고 요구합니다. 이 예시에서는 URI SAN을 spiffe://36cb52cd-4058-f811-0432-6798a240c5d3.consul로 설정합니다.

Update CA Configuration HTTP 엔드포인트를 사용하려면 개인 키와 인증서를 JSON으로 전달해야 합니다:

$ jq --null-input --rawfile key root.key --rawfile cert root.crt '
{
    "Provider": "consul",
    "Config": {
        "LeafCertTTL": "72h",
        "PrivateKey": $key | sub("\\n$"; ""),
        "RootCert": $cert | sub("\\n$"; ""),
        "IntermediateCertTTL": "8760h"
    }
}' > ca_config.json

결과 ca_config.json 파일로 활성 루트 인증서를 업데이트할 수 있습니다:

$ cat ca_config.json
{
  "Provider": "consul",
  "Config": {
    "LeafCertTTL": "72h",
    "PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\nMIIEpAIBAAKCAQEArqiy1c3pbT3cSkjdEM1APALUareU...",
    "RootCert": "-----BEGIN CERTIFICATE-----\nMIIDijCCAnKgAwIBAgIJAOFZ66em1qC7MA0GCSqGSIb3...",
    "IntermediateCertTTL": "8760h"
  }
}

$ curl --request PUT --data @ca_config.json localhost:8500/v1/connect/ca/configuration

...

[INFO] connect: CA rotated to new root under provider "consul"

이제 클러스터는 새 개인 키와 루트 인증서를 사용합니다. 이렇게 CA 구성을 업데이트하면 인증서 회전도 트리거됩니다.

내장 CA

내장 CA (Built-in CA)

본문

구성 (Configuration)

공통 CA 구성 옵션 (Common CA Config Options)

사용자 정의 개인 키와 루트 인증서 지정 (Specifying a Custom Private Key and Root Certificate)

더 알아보기 (Learn more)