유효한 클라이언트 인증서에는 트러스트 저장소의 신뢰 앵커(루트 인증서)로 돌아가는 신뢰 체인이 표시되어야 합니다. 이 페이지에서는 OpenSSL 라이브러리를 사용하여 자체 루트 및 중간 인증서를 구성하여 자체 신뢰 체인을 만드는 방법을 안내합니다.
이 문서에서는 신뢰의 루트를 만든 후 인증서 관리자 TrustConfig
리소스의 트러스트 저장소에 루트를 업로드하는 프로세스를 간략히 설명합니다. 그런 다음 신뢰 구성을 클라이언트 인증 (ServerTLSPolicy
) 리소스에 연결한 후 클라이언트 인증 리소스를 부하 분산기의 대상 HTTPS 프록시 리소스에 연결합니다.
시작하기 전에
- 상호 TLS 개요를 검토합니다.
- 트러스트 구성 관리 가이드를 검토합니다.
Google Cloud CLI 설치 이 도구에 대한 전체 개요는 gcloud CLI 개요를 참조하세요. API 및 gcloud CLI 참조에서 부하 분산과 관련된 명령어를 확인할 수 있습니다.
이전에 gcloud CLI를 실행한 적이 없으면 먼저
gcloud init
명령어를 실행하여 인증합니다.Compute Engine API, Certificate Manager API, 네트워크 보안, Network Services API를 사용 설정합니다. 자세한 내용은 API 사용 설정을 참고하세요.
전역 외부 애플리케이션 부하 분산기 또는 기존 애플리케이션 부하 분산기를 사용하는 경우에는 다음과 같은 지원되는 백엔드 중 하나를 사용하여 부하 분산기를 설정했는지 확인합니다.
- VM 인스턴스 그룹 백엔드
- Cloud Storage 버킷(백엔드 버킷 외에 부하 분산기에 연결된 백엔드 서비스가 하나 이상 있는 경우에만 지원됨)
- Cloud Run, App Engine 또는 Cloud Run Functions
- 하이브리드 연결
리전 외부 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기를 사용하는 경우에는 다음과 같은 지원되는 백엔드 중 하나를 사용하여 부하 분산기를 설정했는지 확인합니다.
- VM 인스턴스 그룹 백엔드
- Cloud Run
- 하이브리드 연결
프로젝트를 설정합니다.
gcloud
gcloud config set project PROJECT_ID
권한
이 가이드를 완료하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 다음 IAM 역할을 부여해 달라고 요청하세요.
-
TargetHTTPSProxy
와 같은 부하 분산기 리소스 만들기: Compute 부하 분산기 관리자(roles/compute.loadBalancerAdmin
) -
인증서 관리자 리소스 사용하기: 인증서 관리자 소유자(
roles/certificatemanager.owner
) -
보안 및 네트워킹 구성요소 만들기: Compute 네트워크 관리자(
roles/compute.networkAdmin
) 및 Compute 보안 관리자(roles/compute.securityAdmin
) -
프로젝트 만들기(선택사항): 프로젝트 생성자(
roles/resourcemanager.projectCreator
)
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.
루트 및 중간 인증서 만들기
이 섹션에서는 OpenSSL 라이브러리를 사용하여 루트 인증서 (신뢰 앵커)와 중간 인증서를 만듭니다.
루트 인증서는 인증서 체인의 맨 위에 있습니다. 중간 인증서는 루트 인증서로 돌아가는 신뢰 체인의 일부입니다. 중간 인증서는 루트 인증서로 암호화 서명됩니다. 부하 분산기가 클라이언트 인증서를 수신하면 클라이언트 인증서에서 구성된 신뢰 앵커로 다시 신뢰 체인을 설정하여 인증합니다.
다음 명령어를 사용하여 루트 인증서와 중간 인증서를 만듭니다. 중간 인증서 생성은 선택사항입니다. 그러나 이 설정에서는 중간 인증서를 사용하여 클라이언트 인증서에 서명합니다.
OpenSSL 구성 파일을 만듭니다.
다음 예에서 구성 파일 (
example.cnf
)에는 인증서를 CA에 적합하다고 표시하는 X.509 확장자를 지정하는[ca_exts]
섹션이 포함되어 있습니다. 루트 및 중간 인증서의 요구사항에 관한 자세한 내용은 인증서 요구사항을 참고하세요.cat > example.cnf << EOF [req] distinguished_name = empty_distinguished_name [empty_distinguished_name] # Kept empty to allow setting via -subj command line arg. [ca_exts] basicConstraints=critical,CA:TRUE keyUsage=keyCertSign extendedKeyUsage=clientAuth EOF
자체 서명 X.509 루트 인증서 (
root.cert
)를 만듭니다. 루트 인증서는 자체 비공개 키 (root.key
)로 자체 서명됩니다.openssl req -x509 \ -new -sha256 -newkey rsa:2048 -nodes \ -days 3650 -subj '/CN=root' \ -config example.cnf \ -extensions ca_exts \ -keyout root.key -out root.cert
중간 인증서의 인증서 서명 요청 (
int.req
)을 만듭니다.openssl req -new \ -sha256 -newkey rsa:2048 -nodes \ -subj '/CN=int' \ -config example.cnf \ -extensions ca_exts \ -keyout int.key -out int.req
CSR에 서명하여 X.509 중간 인증서 (
int.cert
)를 만듭니다. CSR은 루트 인증서를 사용하여 서명됩니다.openssl x509 -req \ -CAkey root.key -CA root.cert \ -set_serial 1 \ -days 3650 \ -extfile example.cnf \ -extensions ca_exts \ -in int.req -out int.cert
허용 목록에 추가할 수 있는 자체 서명 인증서 만들기
자체 서명 인증서를 만들고 신뢰 구성의 허용 목록에 추가할 수 있습니다.
다음 OpenSSL 명령어를 사용하여 자체 서명된 X.509 인증서를 만듭니다.
openssl req -x509 \
-new -sha256 -newkey rsa:2048 -nodes \
-days 3650 -subj '/CN=localhost' \
-keyout allowlisted.key -out allowlisted.cert
그러면 이 인증서가 신뢰 구성의 allowlistedCertificates
필드에 추가됩니다.
인증서 형식 지정
TrustStore
에 새 인증서 또는 기존 인증서를 포함하려면 트러스트 구성 YAML 파일에서 참조할 수 있도록 인증서를 한 줄 형식으로 지정하고 환경 변수에 저장합니다.
export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
트러스트 구성에서 허용 목록에 추가된 새 인증서 또는 기존 인증서를 포함하려면 YAML 파일로 읽어 들일 수 있도록 인증서를 한 줄 형식으로 지정하고 환경 변수에 저장합니다. 허용 목록에 있는 인증서에 대해 다음 명령어를 사용하여 인증서를 단일 줄 형식으로 지정하고 ALLOWLISTED_CERT
환경 변수에 저장합니다.
export ALLOWLISTED_CERT=$(cat allowlisted.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
트러스트 구성 리소스 만들기
트러스트 구성은 인증서 관리자의 공개 키 인프라 (PKI) 구성을 나타내는 리소스입니다.
트러스트 구성 리소스를 만들려면 다음 단계를 완료하세요.
콘솔
Google Cloud 콘솔에서 인증서 관리자 페이지로 이동합니다.
트러스트 구성 탭에서 트러스트 구성 추가를 클릭합니다.
구성의 이름을 입력합니다.
위치에 전역 또는 리전을 선택합니다.
위치는 트러스트 구성 리소스가 저장되는 위치를 나타냅니다. 전역 외부 애플리케이션 부하 분산기, 기존 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 경우 전역 신뢰 구성 리소스를 만듭니다. 리전 외부 애플리케이션 부하 분산기와 리전 내부 애플리케이션 부하 분산기의 경우 리전별 신뢰 구성 리소스를 만듭니다.
리전을 선택한 경우 리전을 선택합니다.
트러스트 저장소 섹션에서 신뢰 앵커 추가를 클릭하고 PEM으로 인코딩된 인증서 파일을 업로드하거나 인증서 내용을 복사합니다.
추가를 클릭합니다.
트러스트 저장소 섹션에서 중간 CA 추가를 클릭하고 PEM으로 인코딩된 인증서 파일을 업로드하거나 인증서 내용을 복사합니다.
이 단계를 통해 루트 인증서와 서버 인증서 간에 신뢰 수준을 한 단계 더 높일 수 있습니다.
추가를 클릭하여 중간 CA를 추가합니다.
선택사항: 허용 목록에 추가된 인증서 섹션에서 인증서 추가를 클릭하고 PEM으로 인코딩된 인증서 파일을 업로드하거나 인증서 내용을 복사합니다.
추가를 클릭하여 허용 목록에 추가된 인증서를 추가합니다.
만들기를 클릭합니다.
새 트러스트 구성 리소스가 구성 목록에 표시되는지 확인합니다.
gcloud
트러스트 구성 매개변수를 지정하는 트러스트 구성 YAML 파일 (
trust_config.yaml
)을 만듭니다. 이 트러스트 구성 리소스 예시에는 신뢰 앵커와 중간 인증서가 포함된 트러스트 저장소가 있습니다. 이전 인증서 형식 지정 단계에서 만든 환경 변수에서 인증서 콘텐츠를 읽습니다.cat << EOF > trust_config.yaml trustStores: - trustAnchors: - pemCertificate: "${ROOT_CERT?}" intermediateCas: - pemCertificate: "${INTERMEDIATE_CERT?}" EOF
추가 신뢰 앵커 또는 중간 인증서를 사용하여 트러스트 저장소를 만들려면 적절한 섹션에
pemCertificate
행을 추가합니다.선택사항:
allowlistedCertificates
필드에서 트러스트 구성 YAML 파일에 추가할 인증서를 지정합니다. 허용 목록에 인증서를 추가하기 위해 트러스트 저장소가 필요하지 않습니다.cat << EOF >> trust_config.yaml allowlistedCertificates: - pemCertificate: "${ALLOWLISTED_CERT?}" EOF
허용 목록에 추가된 인증서는 항상 유효한 것으로 간주되도록 트러스트 구성 내에 캡슐화할 수 있는 모든 인증서를 나타냅니다.
pemCertificate
필드의 여러 인스턴스를 사용하여 허용 목록에 여러 인증서를 지정할 수 있습니다.트러스트 구성 YAML 파일을 가져오려면
gcloud certificate-manager trust-configs import
명령어를 사용합니다.전역
전역 외부 애플리케이션 부하 분산기, 기존 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 경우 신뢰 구성 리소스가 저장되는 위치로
global
를 지정합니다.gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \ --source=trust_config.yaml \ --location=global
다음을 바꿉니다.
TRUST_CONFIG_NAME
: 트러스트 구성 리소스의 이름입니다.
리전
리전 외부 애플리케이션 부하 분산기 및 리전 내부 애플리케이션 부하 분산기의 경우 신뢰 구성 리소스가 저장된 리전을 지정합니다.
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \ --source=trust_config.yaml \ --location=LOCATION
다음을 바꿉니다.
TRUST_CONFIG_NAME
: 트러스트 구성 리소스의 이름입니다.LOCATION
: 트러스트 구성 리소스가 저장되는 리전입니다. 기본 위치는global
입니다.
클라이언트 인증 리소스 만들기
클라이언트 인증 (ServerTLSPolicy
라고도 함) 리소스를 사용하면 클라이언트 인증서 유효성을 검사할 때 사용할 서버 측 TLS 모드와 신뢰 구성 리소스를 지정할 수 있습니다. 클라이언트가 부하 분산기에 잘못된 인증서를 제공하거나 인증서를 제공하지 않으면 clientValidationMode
는 클라이언트 연결이 처리되는 방법을 지정합니다. 자세한 내용은 mTLS 클라이언트 검증 모드를 참고하세요.
clientValidationMode
가ALLOW_INVALID_OR_MISSING_CLIENT_CERT
로 설정되면 검증이 실패하거나 클라이언트 인증서가 없는 경우에도 모든 요청이 백엔드로 전달됩니다.clientValidationMode
가REJECT_INVALID
로 설정되면TrustConfig
리소스에 대해 검증할 수 있는 클라이언트 인증서를 제공하는 요청만 백엔드로 전달됩니다.
클라이언트 인증 (ServerTlsPolicy
) 리소스를 만들려면 다음 단계를 완료하세요.
콘솔
Google Cloud 콘솔에서 클라이언트 인증 페이지로 이동합니다.
클라이언트 인증 만들기를 클릭합니다.
클라이언트 인증 리소스의 이름을 입력합니다.
위치에 전역 또는 리전을 선택합니다.
전역 외부 애플리케이션 부하 분산기, 기존 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 경우 위치를 전역으로 설정합니다. 리전 외부 애플리케이션 부하 분산기 및 리전 내부 애플리케이션 부하 분산기의 경우 위치를 부하 분산기가 구성된 리전으로 설정합니다.
클라이언트 인증 모드에서 부하 분산을 선택합니다.
클라이언트 검증 모드를 선택합니다.
앞에서 만든 트러스트 구성 리소스를 선택합니다.
만들기를 클릭합니다.
클라이언트 인증 (ServerTlsPolicy
)이 표시되는지 확인합니다.
gcloud
연결을 처리하는 방법에 따라 다음 옵션 중 하나를 선택하여 YAML 형식으로 클라이언트 인증(
ServerTlsPolicy
) 리소스를 정의합니다.옵션 1:
clientValidationMode
가ALLOW_INVALID_OR_MISSING_CLIENT_CERT
로 설정되어 있습니다.전역
전역 외부 애플리케이션 부하 분산기, 기존 애플리케이션 부하 분산기, 교차 리전 내부 애플리케이션 부하 분산기의 경우 클라이언트 유효성 검사 모드와 전역 신뢰 구성 리소스를 선언적으로 지정하는 YAML 파일을 만듭니다.
cat << EOF > server_tls_policy.yaml name: SERVER_TLS_POLICY_NAME mtlsPolicy: clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME EOF
리전
리전 외부 애플리케이션 부하 분산기와 리전 내부 애플리케이션 부하 분산기의 경우 클라이언트 유효성 검사 모드와 리전 신뢰 구성 리소스를 선언적으로 지정하는 YAML 파일을 만듭니다.
cat << EOF > server_tls_policy.yaml name: SERVER_TLS_POLICY_NAME mtlsPolicy: clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME EOF
옵션 2:
clientValidationMode
가REJECT_INVALID
로 설정되어 있습니다.전역
전역 외부 애플리케이션 부하 분산기, 기존 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 경우 클라이언트 유효성 검사 모드와 전역 신뢰 구성 리소스를 선언적으로 지정하는 YAML 파일을 만듭니다.
cat << EOF > server_tls_policy.yaml name: SERVER_TLS_POLICY_NAME mtlsPolicy: clientValidationMode: REJECT_INVALID clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME EOF
리전
리전 외부 애플리케이션 부하 분산기와 리전 내부 애플리케이션 부하 분산기의 경우 클라이언트 유효성 검사 모드와 리전 신뢰 구성 리소스를 선언적으로 지정하는 YAML 파일을 만듭니다.
cat << EOF > server_tls_policy.yaml name: SERVER_TLS_POLICY_NAME mtlsPolicy: clientValidationMode: REJECT_INVALID clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME EOF
다음을 바꿉니다.
SERVER_TLS_POLICY_NAME
: 클라이언트 인증 (ServerTlsPolicy
) 리소스의 이름입니다.PROJECT_ID
: Google Cloud 프로젝트의 ID입니다.LOCATION
: 전역 외부 애플리케이션 부하 분산기, 기본 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 경우global
을 사용합니다. 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 부하 분산기를 구성한 리전을 사용합니다.TRUST_CONFIG_NAME
: 이전에 만든 트러스트 구성 리소스의 이름입니다.
클라이언트 인증
ServerTlsPolicy
리소스를 가져오려면gcloud network-security server-tls-policies import
명령어를 사용합니다.전역
전역 외부 애플리케이션 부하 분산기, 기존 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 경우
--location
플래그를global
로 설정합니다.gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \ --source=server_tls_policy.yaml \ --location=global
다음을 바꿉니다.
SERVER_TLS_POLICY_NAME
: 클라이언트 인증 (ServerTlsPolicy
) 리소스의 이름입니다.리전
리전 외부 애플리케이션 부하 분산기와 리전 내부 애플리케이션 부하 분산기의 경우
--location
플래그를 부하 분산기가 구성된 리전으로 설정합니다.gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \ --source=server_tls_policy.yaml \ --location=LOCATION
다음을 바꿉니다.
SERVER_TLS_POLICY_NAME
: 클라이언트 인증 (ServerTlsPolicy
) 리소스의 이름입니다.선택사항: 모든 클라이언트 인증(
ServerTlsPolicies
) 리소스를 나열하려면gcloud network-security server-tls-policies list
명령어를 사용합니다.gcloud network-security server-tls-policies list \ --location=LOCATION
다음을 바꿉니다.
LOCATION
: 전역 외부 애플리케이션 부하 분산기, 기본 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 경우global
을 사용합니다. 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 부하 분산기를 구성한 리전을 사용합니다.
클라이언트 인증 리소스를 부하 분산기에 연결
상호 TLS 인증이 작동하려면 부하 분산기를 설정한 후 클라이언트 인증 (ServerTLSPolicy
) 리소스를 부하 분산기의 대상 HTTPS 프록시 리소스에 연결해야 합니다.
콘솔
Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.
부하 분산기 목록에서 클라이언트 인증 (
ServerTLSPolicy
) 리소스를 연결해야 하는 부하 분산기를 선택합니다.수정을 클릭합니다.
HTTPS 프런트엔드의 프런트엔드 구성 섹션에서 고급 기능 표시 섹션을 펼칩니다.
클라이언트 인증 목록에서 클라이언트 인증 리소스를 선택합니다.
완료를 클릭합니다.
업데이트를 클릭합니다.
gcloud
프로젝트의 모든 대상 HTTPS 프록시 리소스를 나열하려면
gcloud compute target-https-proxies list
명령어를 사용합니다.gcloud compute target-https-proxies list
ServerTLSPolicy
리소스를 연결할 대상 HTTPS 프록시의 이름을 기록해 둡니다. 다음 단계에서는 이 이름을TARGET_HTTPS_PROXY_NAME
이라고 합니다.대상 HTTPS 프록시 구성을 파일로 내보내려면
gcloud compute target-https-proxies export
명령어를 사용합니다.전역
gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \ --destination=TARGET_PROXY_FILENAME \ --global
다음을 바꿉니다.
TARGET_HTTPS_PROXY_NAME
: 대상 프록시 이름TARGET_PROXY_FILENAME
: 타겟 프록시의 구성 파일 이름(YAML 형식)입니다. 예를 들면mtls_target_proxy.yaml
입니다.
리전
gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \ --destination=TARGET_PROXY_FILENAME \ --region=REGION
다음을 바꿉니다.
TARGET_HTTPS_PROXY_NAME
: 대상 프록시 이름TARGET_PROXY_FILENAME
: 타겟 프록시의 구성 파일 이름(YAML 형식)입니다. 예를 들면mtls_target_proxy.yaml
입니다.REGION
: 부하 분산기를 구성한 리전.
모든 클라이언트 인증(
ServerTlsPolicy
) 리소스를 나열하려면gcloud network-security server-tls-policies list
명령어를 사용합니다.gcloud network-security server-tls-policies list \ --location=LOCATION
다음을 바꿉니다.
LOCATION
: 리전 간 내부 애플리케이션 부하 분산기, 전역 외부 애플리케이션 부하 분산기 또는 기존 애플리케이션 부하 분산기에 대해global
을 사용합니다. 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 부하 분산기를 구성한 리전을 사용합니다.mTLS를 구성하려면 클라이언트 인증 (
ServerTLSPolicy
) 리소스 이름을 기록해 둡니다. 이 이름은 다음 단계에서SERVER_TLS_POLICY_NAME
이라고 합니다.대상 HTTPS 프록시에 클라이언트 인증 (
ServerTlsPolicy
)을 추가합니다.echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME
다음을 바꿉니다.
PROJECT_ID
: Google Cloud 프로젝트의 ID입니다.LOCATION
: 전역 외부 애플리케이션 부하 분산기 또는 기존 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 경우global
을 사용합니다. 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 부하 분산기를 구성한 리전을 사용합니다.SERVER_TLS_POLICY_NAME
: 클라이언트 인증 (ServerTLSPolicy
) 리소스의 이름입니다.TARGET_PROXY_FILENAME
: 타겟 프록시의 구성 파일 이름(YAML 형식)입니다.
파일에서 대상 HTTPS 프록시 구성을 가져오려면
gcloud compute target-https-proxies import
명령어를 사용합니다.전역
gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \ --source=TARGET_PROXY_FILENAME \ --global
다음을 바꿉니다.
TARGET_HTTPS_PROXY_NAME
: 대상 프록시 이름TARGET_PROXY_FILENAME
: 타겟 프록시의 구성 파일 이름(YAML 형식)입니다. 예를 들면mtls_target_proxy.yaml
입니다.
리전
gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \ --source=TARGET_PROXY_FILENAME \ --region=REGION
다음을 바꿉니다.
TARGET_HTTPS_PROXY_NAME
: 대상 프록시 이름TARGET_PROXY_FILENAME
: 타겟 프록시의 구성 파일 이름(YAML 형식)입니다. 예를 들면mtls_target_proxy.yaml
입니다.REGION
: 부하 분산기를 구성한 리전.
mTLS 커스텀 헤더 추가
mTLS를 사용 설정하면 커스텀 헤더를 사용하여 mTLS 연결에 대한 정보를 전달할 수 있습니다. 또한 mTLS 연결 실패가 로그에 캡처되도록 로깅을 사용 설정할 수 있습니다.
백엔드 서비스에 mTLS 커스텀 헤더 추가
전역 외부 애플리케이션 부하 분산기 또는 기존 애플리케이션 부하 분산기의 경우 커스텀 헤더를 사용하여 mTLS 연결에 대한 정보를 백엔드 서비스에 전달할 수 있습니다.
프로젝트의 모든 백엔드 서비스를 나열하려면
gcloud compute backend-services list
명령어를 사용합니다.gcloud compute backend-services list
커스텀 헤더 및 로깅을 사용 설정하려면 백엔드 서비스의 이름을 기록해 둡니다. 이 이름은 다음 단계에서
BACKEND_SERVICE
로 참조합니다.백엔드 서비스를 업데이트하려면
gcloud compute backend-services update
명령어를 사용합니다.gcloud compute backend-services update BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate=1 \ --custom-request-header='X-Client-Cert-Present:{client_cert_present}' \ --custom-request-header='X-Client-Cert-Chain-Verified:{client_cert_chain_verified}' \ --custom-request-header='X-Client-Cert-Error:{client_cert_error}' \ --custom-request-header='X-Client-Cert-Hash:{client_cert_sha256_fingerprint}' \ --custom-request-header='X-Client-Cert-Serial-Number:{client_cert_serial_number}' \ --custom-request-header='X-Client-Cert-SPIFFE:{client_cert_spiffe_id}' \ --custom-request-header='X-Client-Cert-URI-SANs:{client_cert_uri_sans}' \ --custom-request-header='X-Client-Cert-DNSName-SANs:{client_cert_dnsname_sans}' \ --custom-request-header='X-Client-Cert-Valid-Not-Before:{client_cert_valid_not_before}' \ --custom-request-header='X-Client-Cert-Valid-Not-After:{client_cert_valid_not_after}'
URL 맵에 mTLS 커스텀 헤더 추가
리전 간 내부 애플리케이션 부하 분산기, 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 커스텀 헤더를 사용하여 mTLS 연결에 대한 정보를 URL 맵에 전달할 수 있습니다.
프로젝트의 모든 URL 맵을 나열하려면 gcloud compute url-maps list
명령어를 사용합니다.
gcloud compute url-maps list
커스텀 헤더와 로깅을 사용 설정하려면 URL 맵의 이름을 기록해 둡니다.
이 이름은 다음 단계에서 URL_MAP_NAME
로 참조됩니다.
전역
리전 간 내부 애플리케이션 부하 분산기의 URL 맵을 수정하려면 gcloud compute
url-maps edit
명령어를 사용합니다.
gcloud compute url-maps edit URL_MAP_NAME --global
다음은 커스텀 요청 헤더(requestHeadersToAdd
)에서 변수를 사용하는 방법을 보여주는 샘플 YAML 파일입니다. 같은 변수를 사용하여 커스텀 응답 헤더(responseHeadersToAdd
)를 전송할 수 있습니다.
headerAction: requestHeadersToAdd: - headerName: "X-Client-Cert-Present" headerValue: "{client_cert_present}" - headerName: "X-Client-Cert-Chain-Verified" headerValue: "{client_cert_chain_verified}" - headerName: "X-Client-Cert-Error" headerValue: "{client_cert_error}" - headerName: "X-Client-Cert-Hash" headerValue: "{client_cert_sha256_fingerprint}" - headerName: "X-Client-Cert-Serial-Number" headerValue: "{client_cert_serial_number}" - headerName: "X-Client-Cert-SPIFFE" headerValue: "{client_cert_spiffe_id}" - headerName: "X-Client-Cert-URI-SANs" headerValue: "{client_cert_uri_sans}" - headerName: "X-Client-Cert-DNSName-SANs" headerValue: "{client_cert_dnsname_sans}" - headerName: "X-Client-Cert-Valid-Not-Before" headerValue: "{client_cert_valid_not_before}" - headerName: "X-Client-Cert-Valid-Not-After" headerValue: "{client_cert_valid_not_after}" - headerName: "X-Client-Cert-Issuer-Dn" headerValue: "{client_cert_issuer_dn}" - headerName: "X-Client-Cert-Subject-Dn" headerValue: "{client_cert_subject_dn}" - headerName: "X-Client-Cert-Leaf" headerValue: "{client_cert_leaf}" - headerName: "X-Client-Cert-Chain" headerValue: "{client_cert_chain}"
리전
리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 URL 맵을 수정하려면 gcloud compute
url-maps edit
명령어를 사용합니다.
gcloud compute url-maps edit URL_MAP_NAME --region=REGION
다음은 커스텀 요청 헤더(requestHeadersToAdd
)에서 변수를 사용하는 방법을 보여주는 샘플 YAML 파일입니다. 같은 변수를 사용하여 커스텀 응답 헤더(responseHeadersToAdd
)를 전송할 수 있습니다.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1 name: regional-lb-map region: region/REGION headerAction: requestHeadersToAdd: - headerName: "X-Client-Cert-Present" headerValue: "{client_cert_present}" - headerName: "X-Client-Cert-Chain-Verified" headerValue: "{client_cert_chain_verified}" - headerName: "X-Client-Cert-Error" headerValue: "{client_cert_error}" - headerName: "X-Client-Cert-Hash" headerValue: "{client_cert_sha256_fingerprint}" - headerName: "X-Client-Cert-Serial-Number" headerValue: "{client_cert_serial_number}" - headerName: "X-Client-Cert-SPIFFE" headerValue: "{client_cert_spiffe_id}" - headerName: "X-Client-Cert-URI-SANs" headerValue: "{client_cert_uri_sans}" - headerName: "X-Client-Cert-DNSName-SANs" headerValue: "{client_cert_dnsname_sans}" - headerName: "X-Client-Cert-Valid-Not-Before" headerValue: "{client_cert_valid_not_before}" - headerName: "X-Client-Cert-Valid-Not-After" headerValue: "{client_cert_valid_not_after}" - headerName: "X-Client-Cert-Issuer-Dn" headerValue: "{client_cert_issuer_dn}" - headerName: "X-Client-Cert-Subject-Dn" headerValue: "{client_cert_subject_dn}" - headerName: "X-Client-Cert-Leaf" headerValue: "{client_cert_leaf}" - headerName: "X-Client-Cert-Chain" headerValue: "{client_cert_chain}"
중간 인증서로 클라이언트 인증서 서명
이 섹션에서는 클라이언트 (리프) 인증서를 생성하는 추가 구성 옵션을 제공합니다. 중간 인증서가 포함된 TrustConfig 리소스를 이미 만든 경우 다음을 실행합니다.
클라이언트 인증서의 CSR을 생성하는 구성 파일을 만듭니다.
다음 구성 파일 (
client.config
)에는 CSR에 포함할 X.509 확장자를 지정하는[extension_requirements]
섹션이 포함되어 있습니다. 클라이언트 인증서 요구사항에 관한 자세한 내용은 인증서 요구사항을 참고하세요.cat > client.config << EOF [req] default_bits = 2048 req_extensions = extension_requirements distinguished_name = dn_requirements prompt = no [extension_requirements] basicConstraints = critical, CA:FALSE keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth [dn_requirements] countryName = US stateOrProvinceName = California localityName = San Francisco 0.organizationName = example organizationalUnitName = test commonName = test.example.com emailAddress = test@example.com EOF
구성 파일에 SPIFFE ID를 연결하려면 다음 단계를 따르세요.
다음과 같이
[extension_requirements]
섹션에subjectAltName
필드를 추가합니다.subjectAltName = @sans_list
다음과 같이
client.config
파일 하단에 새 섹션 ([sans_list]
)을 추가합니다.[sans_list] URI.1 = spiffe://example.com/test-identity
클라이언트 인증서의 CSR (
client.csr
)을 만듭니다.openssl req -new \ -config client.config \ -keyout client.key -out client.csr
CSR에 서명하여 X.509 클라이언트 인증서 (
client.cert
)를 발급합니다. CSR은 중간 인증서로 서명됩니다.openssl x509 -req \ -CAkey int.key -CA int.cert \ -days 365 \ -extfile client.config \ -extensions extension_requirements \ -in client.csr -out client.cert
클라이언트 측 SSL 인증서를 사용하여 부하 분산기의 IP 주소로 안전한 HTTPS 요청을 전송합니다. 클라이언트는 인증서(
client.cert
)를 제공하여 부하 분산기에 자신을 인증합니다.curl -v --key client.key --cert client.cert https://IP_ADDRESS
IP_ADDRESS를 부하 분산기의 IP 주소로 바꿉니다.