이 페이지 개선에 도움 주기
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.
Kubernetes 인증서로 워크로드 보안
Kubernetes Certificates API를 통해 X.509CertificateSigningRequest(CSR) 리소스를 사용할 수 있습니다. 요청은 서명되기 전에 승인되거나 거부됩니다. Kubernetes는 잘 정의된 동작을 통해 기본 제공 서명자와 사용자 지정 서명자를 모두 지원합니다. 이렇게 하면 클라이언트는 CSR에 어떤 일이 일어나는지 예측할 수 있습니다. 인증서 서명에 대한 자세한 내용을 알아보려면 서명 요청
기본 제공 서명자 중 하나는 kubernetes.io/legacy-unknown입니다. CSR 리소스의 v1beta1 API는 이 legacy-unknown 서명자를 준수했습니다. 그러나 CSR의 안정적인 v1 API에서는 signerName이 kubernetes.io/legacy-unknown으로 설정되도록 허용하지 않습니다.
Amazon EKS 1.21 및 이전 버전에서는 legacy-unknown 값을 v1beta1 CSR API의 signerName으로 허용했습니다. 이 API를 사용하면 Amazon EKS CA(인증 기관)에서 인증서를 생성할 수 있습니다. 그러나 Kubernetes 버전 1.22에서는 v1beta1 CSR API가 v1 CSR API로 바뀌었습니다. 이 API는 “legacy-unknown”의 signerName을 지원하지 않습니다. Amazon EKS CA를 사용하여 클러스터에서 인증서를 생성하려는 경우 사용자 지정 서명자를 사용해야 합니다. Amazon EKS 버전 1.22에 도입되었습니다. CSR v1 API 버전을 사용하여 새 인증서를 생성하려면 기존 매니페스트 및 API 클라이언트를 마이그레이션해야 합니다. 기존 v1beta1 API를 사용하여 생성된 기존 인증서는 유효하며 인증서가 만료될 때까지 기능합니다. 다음 내용이 포함됩니다:
-
신뢰 배포: 없음. Kubernetes 클러스터에는 이 서명자에 대한 표준 트러스트나 배포가 없습니다.
-
허용된 과목: 모두
-
허용된 x509 확장 기능: subjectAltName 및 키 사용 확장 기능을 준수하고 다른 확장 기능을 폐기합니다.
-
허용된 키 사용: ["키 암호화”, “디지털 서명”, “서버 인증"] 이외의 용도는 포함하지 않아야 합니다.
참고
클라이언트 인증서 서명은 지원되지 않습니다.
-
만료/인증서 수명: 1년(기본 및 최대)
-
CA 비트 허용됨/허용되지 않음: 허용되지 않음
signerName을 사용한 CSR 생성 예
다음 단계에서는 signerName: beta.eks.amazonaws.com/app-serving을 사용하여 myserver.default.svc DNS 이름에 대한 서빙 인증서를 생성하는 방법을 보여줍니다. 이 정보를 사용자 환경에 대한 가이드로 사용합니다.
-
openssl genrsa -out myserver.key 2048명령을 실행하여 RSA 프라이빗 키를 생성합니다.openssl genrsa -out myserver.key 2048 -
다음 명령을 실행하여 인증 요청을 생성합니다.
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc" -
CSR 요청에 대한
base64값을 생성하고 이후 단계에서 사용할 수 있도록 변수에 저장합니다.base_64=$(cat myserver.csr | base64 -w 0 | tr -d " ") -
다음 명령을 실행하여
mycsr.yaml이라는 파일을 생성합니다. 다음 예에서beta.eks.amazonaws.com/app-serving은signerName입니다.cat >mycsr.yaml <<EOF apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: myserver spec: request: $base_64 signerName: beta.eks.amazonaws.com/app-serving usages: - digital signature - key encipherment - server auth EOF -
CSR을 제출합니다.
kubectl apply -f mycsr.yaml -
서빙 인증서를 승인합니다.
kubectl certificate approve myserver -
인증서가 발급되었는지 확인합니다.
kubectl get csr myserver예제 출력은 다음과 같습니다.
NAME AGE SIGNERNAME REQUESTOR CONDITION myserver 3m20s beta.eks.amazonaws.com/app-serving kubernetes-admin Approved,Issued -
발급된 인증서를 내보냅니다.
kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt
클러스터를 Kubernetes 1.24로 업그레이드하기 전의 인증서 서명 고려 사항
Kubernetes 1.23 이전 버전에서는 kubelet에서 제공되는 확인할 수 없는 IP와 DNS SAN(주체 대체 이름)이 있는 인증서가 확인할 수 없는 SAN과 함께 자동으로 발급됩니다. SAN은 프로비저닝된 인증서에서 생략됩니다. 1.24 및 이후 버전의 클러스터에서는 SAN을 확인할 수 없는 경우 kubelet에서 제공되는 인증서가 발급되지 않습니다. 이렇게 하면 kubectl exec 및 kubectl logs 명령이 작동하지 않습니다.
클러스터를 1.24(으)로 업그레이드하기 전에 다음 단계를 완료하여 승인되지 않은 CSR(인증서 서명 요청)이 있는지 확인하세요.
-
다음 명령을 실행합니다.
kubectl get csr -A예제 출력은 다음과 같습니다.
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION csr-7znmf 90m kubernetes.io/kubelet-serving system:node:ip-192-168-42-149.region.compute.internal <none> Approved csr-9xx5q 90m kubernetes.io/kubelet-serving system:node:ip-192-168-65-38.region.compute.internal <none> Approved, Issued반환된 출력에 노드에 대한 서명자가
Approved이지만Issued가 아닌 kubernetes.io/kubelet-serving서명자가 있는 CSR이 표시되면 요청을 승인해야 합니다. -
CSR을 수동으로 승인합니다.
csr-를 사용자의 고유한 값으로 교체합니다.7znmfkubectl certificate approve csr-7znmf
앞으로 CSR을 자동 승인하려면 Amazon EKS에서 확인할 수 없는 IP 또는 DNS SAN이 포함된 CSR을 자동으로 검증하고 승인할 수 있는 승인 컨트롤러를 작성하는 것이 좋습니다.
