GKE 1.29로 업그레이드하기 전에 TLS 인증서 호환성 확인

Autopilot Standard

버전 1.29 이상을 실행하는 GKE 클러스터는 SHA-1 알고리즘으로 서명된 전송 계층 보안(TLS) 인증서를 지원하지 않습니다. 클러스터에 영향을 주지 않으려면 클러스터를 버전 1.29로 업그레이드하기 전에 웹훅 및 확장 API 서버 백엔드의 호환되지 않는 인증서를 호환 서명 알고리즘을 사용하는 인증서로 바꿔야 합니다.

이 삭제가 클러스터에 미치는 영향

GKE는 클러스터에서 버전 1.29와 호환되지 않는 인증서를 사용하는 것을 감지되면 자동 업그레이드를 일시중지합니다. 인증서를 호환 서명 알고리즘을 사용하는 인증서로 바꾸거나 버전 1.28 지원이 종료되면 GKE에서 자동 업그레이드를 재개합니다.

1.29로 업그레이드하기 전에 호환되지 않는 인증서를 교체하지 않으면 클러스터에 다음과 같은 문제가 발생할 수 있습니다.

SHA-1 알고리즘으로 서명된 TLS 인증서를 사용하는 GKE 웹훅 백엔드의 자동이 인증 실패로 인해 중지됩니다. Kubernetes 제어 영역이 호환되지 않는 인증서로 웹훅과 통신하는 경우 웹훅 호출이 실패합니다. 특히 허용 웹훅을 사용하는 경우 구성에 따라 웹훅 연결 실패로 인해 클러스터에서 리소스 생성(예: 포드 생성)이 차단되어 작업이 중단될 수 있습니다.
확장 API 서버에서 제공하는 API 호출이 실패합니다.

Kubernetes에서 이 기능을 삭제하는 이유

GKE는 오픈소스 Kubernetes를 작동하고 kube-apiserver 구성요소를 사용하여 TLS를 통해 웹훅과 확장 API 서버 백엔드에 연결합니다. kube-apiserver 구성요소는 Go 프로그래밍 언어로 작성됩니다.

Go 버전 1.18부터 Go에서 SHA-1 알고리즘으로 서명된 TLS 인증서를 거부했지만 마이그레이션 프로세스를 간소화하기 위해 이전 동작을 사용 설정하도록 디버그 스위치 x509sha1=1을 남겨 두었습니다. GKE 버전 1.24는 Go 버전 1.18을 사용하여 빌드된 최초의 버전입니다. Kubernetes의 GKE 빌드에서 버전 1.29까지 이 디버그 스위치를 사용 설정했습니다. 스위치는 Go 1.24에서 삭제됩니다. GKE 1.29는 향후 Go에서 디버그 스위치를 제거할 수 있도록 스위치가 중지된 Kubernetes를 빌드합니다. GKE에서 클러스터를 버전 1.29로 업그레이드하면 클러스터의 제어 영역에서 SHA-1 알고리즘으로 서명된 TLS 인증서를 제공하는 클러스터의 웹훅이나 확장 API 서버로의 호출이 실패합니다.

영향을 받는 클러스터 식별

GKE는 클러스터를 모니터링하고 추천자 서비스를 사용하여 SHA-1 알고리즘으로 서명된 TLS 인증서를 사용하는 웹훅이나 확장 API 서버 백엔드가 있는 클러스터를 식별하는 통계와 추천을 통해 지침을 제공합니다. 또는 로그를 사용하여 클러스터에서 영향을 받는 백엔드에 대한 호출을 식별할 수 있습니다.

통계 및 추천을 가져오는 방법

버전 1.24 이상을 실행하는 클러스터의 경우 안내에 따라 통계 및 추천을 봅니다. gcloud CLI 또는 Recommender API를 사용하여 통계를 가져오고 하위유형 DEPRECATION_K8S_SHA_1_CERTIFICATE로 필터링할 수 있습니다.

로그를 가져오는 방법

Cloud Logging이 사용 설정되고 1.24 이상을 실행하는 클러스터의 경우 GKE는 Cloud 감사 로그를 제공하여 클러스터에서 영향을 받는 백엔드에 대한 호출을 식별합니다. 다음 필터를 사용해서 로그를 검색할 수 있습니다.

logName =~ "projects/.*/logs/cloudaudit.googleapis.com%2Factivity"
resource.type = "k8s_cluster"
operation.producer = "k8s.io"
"insecure-sha1.invalid-cert.kubernetes.io"

감사 로그에는 영향을 받는 백엔드의 호스트 이름이 포함됩니다. 결과를 해석하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.

통계 및 추천의 안내 해석

추천에는 영향을 받는 백엔드의 호스트 이름과 웹훅 또는 확장 API 서버인지 여부가 포함됩니다. 클러스터의 서비스를 참조하는 호스트 이름은 <service-name>.<namespace>.svc 형식을 따릅니다.

영향을 받는 백엔드 인증서가 웹훅 서버에서 제공되는 경우 호스트 이름은 클러스터의 서비스나 URL일 수 있습니다. 자세한 내용은 웹훅 문의를 참조하세요.

영향을 받는 인증서가 확장 API 서버에서 제공되는 경우 호스트 이름은 클러스터의 서비스입니다. 자세한 내용은 확장 프로그램 apiserver에 연결을 참조하세요.

영향을 받은 백엔드를 식별한 후 안내를 수행하여 유형에 따라 서비스 인증서를 검사하거나 URL 백엔드 인증서를 검사합니다.

지난 30일 동안 클러스터에서 영향을 받은 인증서가 있는 서버를 호출하지 않은 경우에는 추천이 표시되지 않습니다.

서비스 인증서 검사

서비스에서 웹훅 및 확장 API 서버 모두를 지원할 수 있습니다.

검사할 관련 백엔드 서비스를 식별한 후 다음 안내를 수행하여 각 서비스의 인증서를 검사해 SHA-1 알고리즘을 사용하고 업데이트해야 하는 인증서를 확인합니다.

서비스의 선택기 및 대상 포트를 찾습니다.
```
kubectl describe service --namespace=NAMESPACE SERVICE_NAME
```
NAMESPACE 및 SERVICE_NAME을 targetValue 값으로 바꿉니다.

출력은 다음과 비슷합니다.
```
Name: example-service
Namespace: default
Labels: run=nginx
Selector: run=nginx
Type: ClusterIP
IP: 172.21.xxx.xxx
Port: 443
TargetPort: 444
```
이 출력은 example-service에 선택기 run=nginx 및 대상 포트 444가 있음을 나타냅니다.

참고: TargetPort가 포함되지 않으면 Port 필드와 같은 값입니다.

선택기와 일치하는 포드를 찾습니다.

kubectl get pods --namespace=NAMESPACE --selector=run=nginx

출력은 다음과 비슷합니다.

NAME          READY   STATUS    RESTARTS   AGE
example-pod   1/1     Running   0          21m

이 출력은 일치하는 포드가 example-pod임을 나타냅니다.

포트 전달을 kubectl localhost에서 포드로 설정합니다.

참고: 다음 명령어는 포트 8888을 사용하지만 이 포트는 임의로 선택되므로 개발자가 다른 포트를 선택할 수 있습니다.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
SERVICE_TARGET_PORT를 서비스의 TargetPort 값으로 바꿉니다. TargetPort가 포함되지 않은 경우 Port 값을 사용합니다.
openssl을 사용하여 서비스에서 사용하는 인증서를 표시합니다.
```
openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
```
다음 출력 예시에서는 SHA-256 알고리즘으로 서명된 유효한 인증서를 보여줍니다.
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption
```
이 출력 예시에서는 SHA-1 알고리즘으로 서명된 잘못된 인증서를 보여줍니다.
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption
```
인증서의 출력이 유사한 경우 호환 서명 알고리즘을 사용하도록 인증서를 업데이트해야 합니다. 예를 들어 certificate.k8s.io API를 사용하여 클러스터에서 TLS 인증서를 관리하는 경우 안내에 따라 인증서 서명 요청을 만들 수 있습니다.

포트 전달 삭제

백그라운드에서 실행 중인 포트 전달을 삭제하려면 프로세스를 찾아 종료합니다.

다음 명령어를 실행하여 실행 중인 프로세스를 나열합니다.
```
jobs
```
출력을 참조하여 종료할 프로세스의 ID를 가져옵니다.
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
이 출력 예시에서는 프로세스 ID가 1임을 나타냅니다.
PROCESS_ID를 바꿔 프로세스를 종료합니다.
```
kill %PROCESS_ID
```
다음 출력을 참조합니다.
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
이 출력 예시에서는 프로세스가 종료되었음을 보여줍니다.

URL 백엔드 인증서 검사

웹훅에서 url 백엔드를 사용하는 경우 URL에 지정된 호스트 이름에 직접 연결합니다. 예를 들어 URL이 https://example.com:123/foo/bar이면 다음 openssl 명령어를 사용하여 백엔드에서 사용하는 인증서를 표시합니다.

openssl s_client -connect example.com:123 </dev/null | openssl x509 -noout -text

다음 출력 예시에서는 SHA-256 알고리즘으로 서명된 유효한 인증서를 보여줍니다.

Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption

이 출력 예시에서는 SHA-1 알고리즘으로 서명된 잘못된 인증서를 보여줍니다.

Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption

인증서의 출력이 유사한 경우 호환 서명 알고리즘을 사용하도록 인증서를 업데이트해야 합니다. 예를 들어 certificate.k8s.io API를 사용하여 클러스터에서 TLS 인증서를 관리하는 경우 안내에 따라 인증서 서명 요청을 만들 수 있습니다.

1.29로 업그레이드할 위험 완화

SHA-1 알고리즘으로 서명된 인증서를 사용하여 영향을 받는 클러스터와 백엔드 서비스를 식별한 후에는 클러스터를 버전 1.29로 업그레이드하기 전에 호환 서명 알고리즘이 있는 인증서를 사용하도록 서비스를 업데이트해야 합니다.

영향을 받는 클러스터는 GKE에서 자동으로 감지되고 호환되지 않는 인증서가 더 이상 사용되지 않거나 버전 1.28 지원이 종료될 때까지 버전 1.29로 자동 업그레이드되지 않습니다. 1.28 지원이 종료되면 클러스터가 1.29로 자동 업그레이드됩니다.

호환 서명 알고리즘

GKE 버전 1.29는 Go x509 패키지에서 지원되는 알고리즘과 호환됩니다. 여기에는 다음 알고리즘이 포함됩니다.

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

사용 가능한 알고리즘을 찾으려면 x509.go 소스 파일을 참조하여 UnknownSignatureAlgorithm SignatureAlgorithm = iota를 검색합니다. Go x509 패키지에서 지원하는 알고리즘은 이 줄과 함께 const 블록에 나열됩니다. 지원되지 않고 안전하지 않은 서명 알고리즘을 찾으려면 파일에서 InsecureAlgorithmError 사용을 검색합니다.

리소스

이 변경사항에 대한 상세 설명은 다음 리소스를 참조하세요.