인증서 서명 - Amazon EKS

이 페이지 개선에 도움 주기

이 사용자 설명서에 기여하고 싶으신가요? 이 페이지 하단으로 스크롤하여 GitHub에서 이 페이지 편집을 선택하세요. 여러분의 기여는 모두를 위한 더 나은 사용자 설명서를 만드는 데 도움이 됩니다.

인증서 서명

Kubernetes Certificates API를 통해 X.509 보안 인증 프로비저닝이 자동화됩니다. CA(인증 기관)에서 X.509 인증서를 요청하고 획득할 Kubernetes API 클라이언트의 명령줄 인터페이스가 API에서 추천됩니다. 표시된 서명자가 인증서에 서명하도록 요청하는 데 CertificateSigningRequest(CSR) 리소스를 사용할 수 있습니다. 요청은 서명되기 전에 승인 또는 거부됩니다. Kubernetes에서는 잘 정의된 동작이 있는 기본 제공 서명자와 사용자 지정 서명자를 모두 지원합니다. 이렇게 하면 클라이언트는 CSR에 어떤 일이 일어나는지 예측할 수 있습니다. 인증서 서명에 대한 자세한 내용을 알아보려면 서명 요청을 참조하세요.

기본 제공 서명자 중 하나는 kubernetes.io/legacy-unknown입니다. CSR 리소스의 v1beta1 API는 이 legacy-unknown 서명자를 준수했습니다. 그러나 CSR의 안정적인 v1 API에서는 signerNamekubernetes.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 이름에 대한 서빙 인증서를 생성하는 방법을 보여줍니다. 이 정보를 사용자 환경에 대한 가이드로 사용합니다.

  1. openssl genrsa -out myserver.key 2048 명령을 실행하여 RSA 프라이빗 키를 생성합니다.

    openssl genrsa -out myserver.key 2048
  2. 다음 명령을 실행하여 인증 요청을 생성합니다.

    openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
  3. CSR 요청에 대한 base64 값을 생성하고 이후 단계에서 사용할 수 있도록 변수에 저장합니다.

    base_64=$(cat myserver.csr | base64 -w 0 | tr -d "\n")
  4. 다음 명령을 실행하여 mycsr.yaml이라는 파일을 생성합니다. 다음 예에서 beta.eks.amazonaws.com/app-servingsignerName입니다.

    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
  5. CSR을 제출합니다.

    kubectl apply -f mycsr.yaml
  6. 서빙 인증서를 승인합니다.

    kubectl certificate approve myserver
  7. 인증서가 발급되었는지 확인합니다.

    kubectl get csr myserver

    예제 출력은 다음과 같습니다.

    NAME AGE SIGNERNAME REQUESTOR CONDITION myserver 3m20s beta.eks.amazonaws.com/app-serving kubernetes-admin Approved,Issued
  8. 발급된 인증서를 내보냅니다.

    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 execkubectl logs 명령이 작동하지 않습니다.

클러스터를 1.24(으)로 업그레이드하기 전에 다음 단계를 완료하여 승인되지 않은 CSR(인증서 서명 요청)이 있는지 확인하세요.

  1. 다음 명령을 실행합니다.

    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

    반환된 출력에 노드에 대한 Issued이(가) 아니라 Approvedkubernetes.io/kubelet-serving 서명자와 함께 CSR이 표시되면 요청을 승인해야 합니다.

  2. CSR을 수동으로 승인합니다. csr-7znmf를 사용자의 고유한 값으로 교체합니다.

    kubectl certificate approve csr-7znmf

앞으로 CSR을 자동 승인하려면 Amazon EKS에서 확인할 수 없는 IP 또는 DNS SAN이 포함된 CSR을 자동으로 검증하고 승인할 수 있는 승인 컨트롤러를 작성하는 것이 좋습니다.