이제 베어메탈용 Anthos 클러스터는 베어메탈용 Google Distributed Cloud(소프트웨어 전용)입니다. 자세한 내용은 제품 개요를 참조하세요.

커스텀 클러스터 인증 기관 사용

클러스터 인증 기관(CA)은 인증서를 발급하고 서명하여 클러스터 구성요소 간의 보안 인증 및 암호화를 지원합니다. 기본적으로 Google Distributed Cloud에서는 새 클러스터를 만들 때 클러스터 API가 클러스터 CA를 만듭니다. 이 문서에서는 Google Distributed Cloud에서 고유한 인증 기관을 사용하는 방법을 설명합니다. 커스텀 클러스터 CA를 사용하면 클러스터 인증서를 발급하고 관리하는 더 많은 제어 기능을 사용할 수 있습니다. 또한 신뢰, 암호화 알고리즘 매개변수, 하위 인증서의 깊이와 목적을 제어할 수 있습니다.

커스텀 CA를 사용하려면 CA 인증서 파일 및 해당 비공개 키 파일로 구성된 루트 CA를 제공해야 합니다. 다음과 같은 각 필수 클러스터 CA에 대해 CA 인증서와 키 파일 쌍을 제공합니다.

etcd CA: etcd CA 인증서는 Kubernetes API 서버에서 etcd 복제본으로의 통신과 etcd 복제본 간 통신도 보호합니다.
클러스터 CA: 클러스터 CA의 인증서는 Kubernetes API 서버와 모든 내부 Kubernetes API 클라이언트 사이의 통신을 보호합니다. 클라이언트에는 kubelet, 컨트롤러 관리자, 스케줄러가 포함됩니다.
프런트 프록시 CA: 프런트 프록시 CA의 인증서는 집계된 API와의 통신을 보호합니다.

각 CA에 대해 고유한 인증서-키 쌍을 제공하거나 둘 이상의 CA에 인증서-키 쌍을 재사용할 수 있습니다.

클러스터 만들기(bmctl 메서드만 해당) 및 CA 순환 중에 인증서-키 쌍을 적용합니다. 커스텀 클러스터 CA 기능은 관리자, 사용자, 하이브리드, 독립형의 모든 클러스터 유형에서 작동합니다.

기본 요건

사용자는 다음 규칙에 따라 자체 루트 CA를 준비해야 합니다.

커스텀 CA는 루트 CA이며 각각 자체 서명된 인증서 파일과 비공개 키 파일로 구성됩니다.
인증서에 대해 고유 인코딩 규칙(DER) 형식을 사용하는 것이 좋습니다(ASN.1 인코딩 규칙에 대한 권장사항 X.690 참조). 인증서 파일에는 base64로 인코딩된 데이터(앞에는 ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑, 뒤에는 ‑‑‑‑END CERTIFICATE‑‑‑‑‑가 있음)가 포함되어야 합니다.
비공개 키의 경우 공개 키 암호화 표준(PKCS) #1 형식을 사용하는 것이 좋습니다. 키 파일에는 base64로 인코딩된 데이터(앞에는 ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑, 뒤에는 ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑가 있음)가 포함되어야 합니다.
잠재적인 클러스터 중단을 최소화하기 위해서는 커스텀 CA가 5년 이내에 만료되지 않아야 합니다. 만료 시간을 10~30년 정도로 길게 설정하는 것이 좋습니다.
인증서와 키 파일이 bmctl 명령어를 실행하는 관리자 워크스테이션에 있는지 확인합니다.
bmctl 명령어를 실행하는 사용자는 파일을 저장하는 디렉터리에 대한 액세스 권한이 있어야 합니다. 인증서 및 키에 사용되는 기존 디렉터리에 파일을 배치하는 것이 좋습니다. 예를 들어 서비스 계정 키와 함께 ~/baremetal/bmctl-workspace/.sa-keys에 파일을 저장할 수 있습니다.
bmctl 명령어를 실행하는 사용자는 파일에 대한 읽기 권한이 있어야 합니다.

클러스터 생성 중 커스텀 CA 사용

bmctl로 클러스터를 만들 때는 먼저 클러스터 구성 파일을 업데이트하여 클러스터 기능 및 설정을 기술합니다. 클러스터를 만드는 동안 커스텀 클러스터 CA 기능을 사용하려면 클러스터 구성 파일에 커스텀 클러스터 CA를 지정하는 두 가지 옵션이 있습니다.

CA 인증서 파일과 비공개 키 파일의 경로 지정
비공개 키 파일의 경로만 지정

비공개 키만 지정하면 bmctl이 동일한 디렉터리에서 해당 CA 인증서 파일을 찾습니다. 인증서 파일 이름은 해당하는 비공개 키 파일 및 .crt 파일 확장자와 동일해야 합니다. 예를 들어 비공개 키 경로가 /custom-ca/cluster_ca.key이면 bmctl은 인증서 경로를 /custom-ca/cluster_ca.crt으로 간주합니다.

어느 경우에나 경로는 다음 예시에 표시된 대로 구성 파일의 사용자 인증 정보 섹션에 지정됩니다.

예시 1: 인증서와 키 경로 지정

다음과 같은 클러스터 구성 파일의 발췌물은 각 클러스터 CA의 인증서 및 키 파일 모두에 경로를 지정하는 방법을 보여줍니다. 이 예시에서 CA 인증서와 키 파일은 서비스 계정 JSON 키 파일과 동일한 디렉터리에 있습니다.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

예시 2: 비공개 키 경로만 지정

다음과 같은 클러스터 구성 파일의 발췌문은 키 파일 경로만 지정하는 방법을 보여줍니다. 이 예시에서 CA 비공개 키 파일은 서비스 계정 JSON 키 파일과 동일한 디렉터리에 있습니다. 해당 CA 인증서 파일은 /.sa-keys 디렉터리에도 있어야 합니다. 인증서 파일은 키 파일과 이름이 같지만 .crt 확장자가 사용됩니다. 따라서 etcd CA 인증서 파일 이름은 etcd_ca.crt입니다.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

예시 3: CA 인증서와 키 파일의 단일 쌍 재사용

다음과 같은 클러스터 구성 파일의 발췌문은 키 파일 경로만 지정하는 방법을 보여줍니다. 이 예시에서는 모든 클러스터 CA에 단일 인증서-키 쌍이 사용됩니다. CA 인증서와 비공개 키 파일은 모두 /custom-ca 디렉터리에 있습니다. 이름 지정 규칙에 따라 CA 인증서 파일 이름은 custom_ca.crt입니다.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

CA 순환 중 커스텀 CA 사용

CA를 순환할 때 커스텀 클러스터 CA 인증서 및 비공개 키 파일의 경로를 지정할 수 있습니다. 제공되는 옵션은 클러스터를 만들 때 커스텀 클러스터 CA를 지정하는 옵션과 유사합니다. bmctl update credentials certificate-authorities rotate 명령어를 실행할 때 옵션은 다음과 같습니다.

커스텀 CA 인증서 파일과 비공개 키 파일 모두의 경로를 지정합니다.
커스텀 CA 비공개 키 파일의 경로만 지정합니다. 해당 CA 인증서 파일은 동일한 디렉터리에 있어야 하고 키 파일과 이름이 동일하며 .crt 파일 확장자를 가져야 합니다.
둘 이상의 클러스터 CA에 대해 동일한 인증서 및 키 경로를 지정하여 CA 인증서-키 쌍을 재사용합니다.
커스텀 CA 경로의 인수를 생략합니다. CA를 순환할 때 커스텀 CA 경로를 지정하지 않으면 Google Distributed Cloud에서 표준 클러스터 CA를 만들어 사용합니다.

예시 1: CA 인증서 및 비공개 키 경로 지정

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

다음을 바꿉니다.

CLUSTER_NAME: CA를 순환하려는 클러스터의 이름입니다.
ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로 자체 관리 클러스터의 경우 이 파일은 클러스터의 kubeconfig 파일입니다.
CLUSTER_CA_CERT_PATH: 클러스터 CA 인증서 파일의 경로입니다.
CLUSTER_CA_KEY_PATH: 클러스터 CA 비공개 키 파일의 경로입니다.
ETCD_CA_CERT_PATH: etcd CA 인증서 파일의 경로입니다.
ETCD_CA_KEY_PATH: etcd CA 비공개 키 파일의 경로입니다.
FRONT_PROXY_CA_CERT_PATH: 프런트 프록시 인증서 파일의 경로입니다.
FRONT_PROXY_CA_KEY_PATH: 프런트 프록시 비공개 키 파일의 경로입니다.

예시 2: 비공개 키 경로만 지정

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

다음을 바꿉니다.

CLUSTER_NAME: CA를 순환하려는 클러스터의 이름입니다.
ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로 자체 관리 클러스터의 경우 이 파일은 클러스터의 kubeconfig 파일입니다.
CLUSTER_CA_KEY_PATH: 클러스터 CA 비공개 키 파일의 경로입니다.
ETCD_CA_KEY_PATH: etcd CA 비공개 키 파일의 경로입니다.
FRONT_PROXY_CA_KEY_PATH: 프런트 프록시 비공개 키 파일의 경로입니다.

중개 CA

버전 1.29 클러스터는 미리보기 기능으로 중개 CA 사용을 지원합니다. 이 기능은 지원되는 모든 제품 버전에서 동일한 출시 단계에 있는 것은 아닙니다.

1.29: 미리보기
1.28: 사용할 수 없음
1.16: 사용할 수 없음

커스텀 CA의 루트 CA 요구사항과 마찬가지로 중개 CA를 사용하려면 3개의 CA 집합을 준비해야 합니다. 각 CA는 CA 인증서 파일과 해당 비공개 키 파일로 구성됩니다. 다음과 같은 각 필수 클러스터 CA에 대해 CA 인증서와 키 파일 쌍을 제공합니다.

etcd CA
클러스터 CA
프런트 프록시 CA

루트 CA와 마찬가지로 각 CA에 대해 고유한 인증서-키 쌍을 제공하거나 CA 구성에 동일한 파일 경로를 지정하여 둘 이상의 CA에 인증서-키 쌍을 재사용할 수 있습니다.

중개 CA를 사용하는 경우 CA 인증서 파일에는 중개 CA에서 루트 CA까지의 인증서를 포함하는 전체 인증서 체인이 포함되어야 합니다. 인증서는 서명 방법의 역순으로 나열되며 상단에 마지막 중개 CA 인증서가 있고 루트 CA 인증서가 하단에 있습니다.

다음 예시에서 (하단의 루트 CA부터 시작되는) 순서는 다음을 나타냅니다.

루트 CA가 Intermediate-A CA 인증서에 서명함
Intermediate-A CA가 Intermediate-B CA 인증서에 서명함
체인은 Intermediate-X CA에서 서명한 최종 Intermediate-Y CA 인증서까지 계속 진행됩니다.

이 예시를 계속하려면 Intermediate-Y CA 인증서와 연결된 비공개 키를 커스텀 CA와 동일한 방식으로 CA 인증서 체인과 함께 전달해야 합니다.

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

클러스터가 중개 CA를 사용 중인지 확인하려면 클러스터의 CA 보안 비밀에서 인증서 수를 검사합니다.

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l