CSR

Created: 2022년 4월 3일 오후 10:29
Updated: 2022년 4월 3일 오후 10:29

인증서 서명 요청

기능 상태: Kubernetes v1.19 [stable]

Certificates API는 Kubernetes API의 클라이언트가 X.509를 요청하고 얻을 수 있도록 프로그래밍 방식의 인터페이스를 제공하여 X.509 자격 증명 프로비저닝을 자동화할 수 있습니다.인증서인증 기관(CA)에서.

CertificateSigningRequest(CSR) 리소스는 지정된 서명자가 인증서에 서명하도록 요청하는 데 사용되며, 그 후에 최종 서명되기 전에 요청이 승인되거나 거부될 수 있습니다.

서명 절차 요청

CertificateSigningRequest 리소스 유형을 사용하면 클라이언트가 서명 요청에 따라 X.509 인증서 발급을 요청할 수 있습니다. CertificateSigningRequest 개체는 필드에 PEM으로 인코딩된 PKCS#10 서명 요청을 포함 spec.request합니다. spec.signerNameCertificateSigningRequest는 필드 를 사용하여 서명자(요청을 받는 수신자)를 나타냅니다 . spec.signerNameAPI 버전 이후 필수 키 입니다 certificates.k8s.io/v1. Kubernetes v1.22 이상에서 클라이언트는 선택적으로 spec.expirationSeconds 발급된 인증서의 특정 수명을 요청하도록 필드를 설정할 수 있습니다. 이 필드의 최소 유효한 값은 600, 즉 10분입니다.

일단 생성된 CertificateSigningRequest는 서명되기 전에 승인되어야 합니다. 선택한 서명자에 따라 CertificateSigningRequest가 자동으로 승인될 수 있습니다.제어 장치. 그렇지 않으면 CertificateSigningRequest는 REST API(또는 client-go)를 통해 또는 kubectl certificate approve. 마찬가지로, CertificateSigningRequest도 거부될 수 있으며, 이는 구성된 서명자에게 요청에 서명하지 않아야 함을 알려줍니다.

승인된 인증서의 다음 단계는 서명입니다. 관련 서명 컨트롤러는 먼저 서명 조건이 충족되었는지 확인한 다음 인증서를 생성합니다. status.certificate그런 다음 서명 컨트롤러는 CertificateSigningRequest를 업데이트 하여 기존 CertificateSigningRequest 객체 의 필드에 새 인증서를 저장 합니다. status.certificate필드가 비어 있거나 PEM 형식으로 인코딩된 X.509 인증서가 포함되어 있습니다 . status.certificate서명자가 이를 수행할 때까지 CertificateSigningRequest 필드는 비어 있습니다.

필드가 채워 지면 status.certificate요청이 완료되고 클라이언트는 이제 CertificateSigningRequest 리소스에서 서명된 인증서 PEM 데이터를 가져올 수 있습니다. 서명자는 승인 조건이 충족되지 않으면 대신 인증서 서명을 거부할 수 있습니다.

클러스터에 남아 있는 오래된 CertificateSigningRequest 리소스의 수를 줄이기 위해 가비지 수집 컨트롤러가 주기적으로 실행됩니다. 가비지 수집은 일정 기간 동안 상태가 변경되지 않은 CertificateSigningRequests를 제거합니다.

• 승인된 요청: 1시간 후 자동 삭제
• 거부된 요청: 1시간 후 자동 삭제
• 실패한 요청: 1시간 후 자동 삭제
• 대기 중인 요청: 24시간 후 자동 삭제
• 모든 요청: 발급된 인증서 만료 후 자동 삭제

서명자

사용자 지정 서명자 이름도 지정할 수 있습니다. 모든 서명자는 클라이언트가 CSR에 어떤 일이 일어날지 예측할 수 있도록 작업 방식에 대한 정보를 제공해야 합니다. 여기에는 다음이 포함됩니다.

1. 신뢰 분배

   : 신뢰(CA 번들)가 분배되는 방법.

2. 허용된 주제

   : 허용되지 않는 주제가 요청될 때의 모든 제한 및 행동.

3. 허용되는 x509 확장

   : IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames 등을 포함하며 허용되지 않는 확장이 요청될 때의 동작입니다.

4. 허용된 키 사용/확장된 키 사용

   : 서명자가 결정한 사용과 다른 사용이 CSR에 지정된 경우에 대한 모든 제한 및 동작.

5. 만료/인증서 수명spec.expirationSecondsspec.expirationSeconds

   : 서명자에 의해 고정되는지, 관리자에 의해 구성 가능한지, CSR

   필드에 의해 결정되는지, 그리고 서명자가 결정한 만료일이 CSR 필드와 다를 때의 동작

   .

6. CA 비트 허용/비허용

   : 서명자가 허용하지 않을 때 CSR에 CA 인증서에 대한 요청이 포함된 경우 동작.

일반적으로 status.certificate필드에는 CSR이 승인되고 인증서가 발급되면 단일 PEM으로 인코딩된 X.509 인증서가 포함됩니다. 일부 서명자는 여러 인증서를 status.certificate필드에 저장합니다. 이 경우 서명자를 위한 문서는 추가 인증서의 의미를 지정해야 합니다. 예를 들어, 이것은 인증서와 TLS 핸드셰이크 중에 표시될 중간체일 수 있습니다.

PKCS#10 서명 요청 형식에는 인증서 만료 또는 수명을 지정하는 표준 메커니즘이 없습니다. 따라서 만료 또는 수명 spec.expirationSeconds은 CSR 개체의 필드를 통해 설정되어야 합니다. 기본 제공 서명자는 ClusterSigningDuration구성 옵션을 사용하며 기본값은 1년이며(kube-controller-manager의 명령줄 플래그) no 가 지정 --cluster-signing-duration되면 기본값으로 사용 됩니다. spec.expirationSeconds가 지정 되면 및 spec.expirationSeconds 의 최소값 이 사용됩니다.spec.expirationSecondsClusterSigningDuration

참고: 이 spec.expirationSeconds필드는 Kubernetes v1.22에 추가되었습니다. 이전 버전의 Kubernetes는 이 필드를 사용하지 않습니다. v1.22 이전의 Kubernetes API 서버는 객체가 생성될 때 이 필드를 자동으로 삭제합니다.

Kubernetes 서명자

Kubernetes는 각각 다음과 같이 잘 알려진 내장 서명자를 제공합니다 signerName.

1. kubernetes.io/kube-apiserver-client: API 서버에서 클라이언트 인증서로 인정할 인증서에 서명합니다. 자동 승인 없음kube 컨트롤러 관리자.

   1. 신뢰 배포: 서명된 인증서는 API 서버에서 클라이언트 인증서로 인정해야 합니다. CA 번들은 다른 방법으로 배포되지 않습니다.

   2. 허용된 주제 - 주제 제한은 없지만 승인자와 서명자는 승인 또는 서명하지 않도록 선택할 수 있습니다. 클러스터 관리자 수준의 사용자 또는 그룹과 같은 특정 주제는 배포와 설치에 따라 다르지만 승인 및 서명 전에 추가 조사가 필요합니다. 허용 플러그인 은 CertificateSubjectRestrictionsystem:masters

      기본적으로 제한하도록 활성화되어

      있지만 클러스터의 유일한 클러스터 관리자 주제가 아닌 경우가 많습니다.

   3. 허용된 x509 확장 - subjectAltName 및 키 사용 확장을 존중하고 다른 확장은 무시합니다.

   4. 허용된 키 사용 - 을 포함해야 합니다 ["client auth"]["digital signature", "key encipherment", "client auth"]

      . 을(를) 초과하는 키 사용을 포함하지 않아야 합니다

      .

   5. 만료/인증서 수명 - 이 서명자의 kube-controller-manager 구현의 경우 -cluster-signing-durationspec.expirationSeconds

      옵션의 최소값으로 설정하거나 지정된 경우

      CSR 개체의 필드로 설정합니다.

   6. CA 비트 허용/비허용 - 허용되지 않습니다.

2. kubernetes.io/kube-apiserver-client-kubelet: API 서버에서 클라이언트 인증서로 인정할 클라이언트 인증서에 서명합니다. 에 의해 자동 승인될 수 있음kube 컨트롤러 관리자.

   1. 신뢰 배포: 서명된 인증서는 API 서버에서 클라이언트 인증서로 인정해야 합니다. CA 번들은 다른 방법으로 배포되지 않습니다.

   2. 허용되는 주제 - 조직은 정확히 ["system:nodes"]system:node:

      " "로 시작하는 공통 이름

      입니다.

   3. 허용된 x509 확장 - 주요 사용 확장을 존중하고 subjectAltName 확장을 금지하고 다른 확장을 삭제합니다.

   4. 허용된 키 사용 - 정확히 ["key encipherment", "digital signature", "client auth"]

      .

   5. 만료/인증서 수명 - 이 서명자의 kube-controller-manager 구현의 경우 -cluster-signing-durationspec.expirationSeconds

      옵션의 최소값으로 설정하거나 지정된 경우

      CSR 개체의 필드로 설정합니다.

   6. CA 비트 허용/비허용 - 허용되지 않습니다.

3. kubernetes.io/kubelet-serving: API 서버에서 유효한 kubelet 제공 인증서로 인정하지만 다른 보장은 없는 인증서 제공에 서명합니다. 자동 승인 없음kube 컨트롤러 관리자.

   1. 신뢰 배포: API 서버는 서명된 인증서를 kubelet에 대한 연결을 종료하는 데 유효한 것으로 인정해야 합니다. CA 번들은 다른 방법으로 배포되지 않습니다.

   2. 허용되는 주제 - 조직은 정확히 ["system:nodes"]system:node:

      " "로 시작하는 공통 이름

      입니다.

   3. 허용된 x509 확장 - 키 사용 및 DNSName/IPAddress subjectAltName 확장을 존중하고 EmailAddress 및 URI subjectAltName 확장을 금지하고 다른 확장을 삭제합니다. 하나 이상의 DNS 또는 IP subjectAltName이 있어야 합니다.

   4. 허용된 키 사용 - 정확히 ["key encipherment", "digital signature", "server auth"]

      .

   5. 만료/인증서 수명 - 이 서명자의 kube-controller-manager 구현의 경우 -cluster-signing-durationspec.expirationSeconds

      옵션의 최소값으로 설정하거나 지정된 경우

      CSR 개체의 필드로 설정합니다.

   6. CA 비트 허용/비허용 - 허용되지 않습니다.

4. kubernetes.io/legacy-unknown: 신뢰에 대한 보장이 전혀 없습니다. Kubernetes의 일부 타사 배포는 해당 배포가 서명한 클라이언트 인증서를 사용할 수 있습니다. 안정적인 CertificateSigningRequest API(버전 certificates.k8s.io/v1이상)에서는 로 설정할 수 signerName없습니다 kubernetes.io/legacy-unknown. 자동 승인 없음kube 컨트롤러 관리자.

   1. 신뢰 분배: 없음. Kubernetes 클러스터에서 이 서명자에 대한 표준 신뢰 또는 배포가 없습니다.

   2. 허용 과목 - 모든

   3. 허용된 x509 확장 - subjectAltName 및 키 사용 확장을 존중하고 다른 확장은 무시합니다.

   4. 허용된 키 사용 - 모두

   5. 만료/인증서 수명 - 이 서명자의 kube-controller-manager 구현의 경우 -cluster-signing-durationspec.expirationSeconds

      옵션의 최소값으로 설정하거나 지정된 경우

      CSR 개체의 필드로 설정합니다.

   6. CA 비트 허용/비허용 - 허용되지 않습니다.

참고: 이들 모두에 대한 실패는 kube-controller-manager 로그에만 보고됩니다.

참고: 이 spec.expirationSeconds필드는 Kubernetes v1.22에 추가되었습니다. 이전 버전의 Kubernetes는 이 필드를 사용하지 않습니다. v1.22 이전의 Kubernetes API 서버는 객체가 생성될 때 이 필드를 자동으로 삭제합니다.

신뢰 분배는 이러한 서명자에 대해 대역 외에서 발생합니다. 위에 설명된 것 이외의 신뢰는 전적으로 우연의 일치입니다. 예를 들어, 일부 배포판은 kubernetes.io/legacy-unknownkube-apiserver에 대한 클라이언트 인증서로 인정할 수 있지만 이것은 표준이 아닙니다. 이러한 사용법은 .data[ca.crt]어떤 식으로든 ServiceAccount 토큰 비밀과 관련이 없습니다. 해당 CA 번들은 기본 서비스( )를 사용하여 API 서버에 대한 연결을 확인하는 것만 보장됩니다 kubernetes.default.svc.

권한 부여

CertificateSigningRequest 생성 및 CertificateSigningRequest 검색을 허용하려면:

• 동사: creategetlistwatchcertificates.k8s.iocertificatesigningrequests , , , , 그룹: , 리소스:
  

예를 들어:

[access/certificate-signing-request/clusterrole-create.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/access/certificate-signing-request/clusterrole-create.yaml)

`apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: csr-creator
rules:

• apiGroups:
  • certificates.k8s.io
    resources:
  • certificatesigningrequests
    verbs:
  • create
  • get
  • list
  • watch`

CertificateSigningRequest 승인을 허용하려면:

• 동사: getlistwatchcertificates.k8s.iocertificatesigningrequests , , , 그룹: , 리소스:
  
• 동사: updatecertificates.k8s.iocertificatesigningrequests/approval , 그룹: , 리소스:
  
• 동사: approvecertificates.k8s.iosigners<signerNameDomain>/<signerNamePath><signerNameDomain>/* , 그룹: , 리소스: , 리소스 이름: 또는
  

예를 들어:

[access/certificate-signing-request/clusterrole-approve.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/access/certificate-signing-request/clusterrole-approve.yaml)

`apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: csr-approver
rules:

• apiGroups:
  • certificates.k8s.io
    resources:
  • certificatesigningrequests
    verbs:
  • get
  • list
  • watch
• apiGroups:
  • certificates.k8s.io
    resources:
  • certificatesigningrequests/approval
    verbs:
  • update
• apiGroups:
  • certificates.k8s.io
    resources:
  • signers
    resourceNames:
  • example.com/my-signer-name # example.com/ can be used to authorize for all signers in the 'example.com' domain*verbs:
  • approve`

CertificateSigningRequest 서명을 허용하려면:

• 동사: getlistwatchcertificates.k8s.iocertificatesigningrequests , , , 그룹: , 리소스:
  
• 동사: updatecertificates.k8s.iocertificatesigningrequests/status , 그룹: , 리소스:
  
• 동사: signcertificates.k8s.iosigners<signerNameDomain>/<signerNamePath><signerNameDomain>/* , 그룹: , 리소스: , 리소스 이름: 또는
  

[access/certificate-signing-request/clusterrole-sign.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/access/certificate-signing-request/clusterrole-sign.yaml)

`apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: csr-signer
rules:

• apiGroups:
  • certificates.k8s.io
    resources:
  • certificatesigningrequests
    verbs:
  • get
  • list
  • watch
• apiGroups:
  • certificates.k8s.io
    resources:
  • certificatesigningrequests/status
    verbs:
  • update
• apiGroups:
  • certificates.k8s.io
    resources:
  • signers
    resourceNames:
  • example.com/my-signer-name # example.com/ can be used to authorize for all signers in the 'example.com' domain*verbs:
  • sign`

일반 사용자

일반 사용자가 API를 인증하고 호출할 수 있게 하려면 몇 가지 단계가 필요합니다. 먼저 이 사용자는 Kubernetes 클러스터에서 발급한 인증서가 있어야 하며 해당 인증서를 Kubernetes API에 제시해야 합니다.

개인 키 생성

다음 스크립트는 PKI 개인 키와 CSR을 생성하는 방법을 보여줍니다. CSR의 CN 및 O 속성을 설정하는 것이 중요합니다. CN은 사용자의 이름이고 O는 이 사용자가 속할 그룹입니다. 표준 그룹에 대해서는 RBAC 를 참조할 수 있습니다 .

openssl genrsa -out myuser.key 2048 openssl req -new -key myuser.key -out myuser.csr

CertificateSigningRequest 생성

CertificateSigningRequest를 생성하고 kubectl을 통해 Kubernetes 클러스터에 제출합니다. 다음은 CertificateSigningRequest를 생성하는 스크립트입니다.

`cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: myuser
spec:
request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
signerName: kubernetes.io/kube-apiserver-client
expirationSeconds: 86400 # one day
usages:

• client auth
  EOF`

참고 사항:

• usagesclient auth ' ' 이어야 합니다.
  
• expirationSeconds8640003600 더 길게(즉 , 10일 동안) 또는 더 짧게(즉 , 1시간 동안) 만들 수 있습니다.
  
• requestcat myuser.csr | base64 | tr -d "\n" CSR 파일 콘텐츠의 base64 인코딩 값입니다. 다음 명령을 사용하여 콘텐츠를 가져올 수 있습니다.
  

인증서 서명 요청 승인

kubectl을 사용하여 CSR을 생성하고 승인합니다.

CSR 목록 가져오기:

kubectl get csr

CSR 승인:

kubectl certificate approve myuser

인증서 받기

CSR에서 인증서를 검색합니다.

kubectl get csr/myuser -o yaml

인증서 값은 에서 Base64로 인코딩된 형식 status.certificate입니다.

CertificateSigningRequest에서 발급된 인증서를 내보냅니다.

kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt

역할 및 RoleBinding 만들기

인증서가 생성되면 이 사용자가 Kubernetes 클러스터 리소스에 액세스할 수 있도록 Role 및 RoleBinding을 정의할 차례입니다.

다음은 이 새 사용자에 대한 역할을 생성하는 샘플 명령입니다.

kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods

다음은 이 새 사용자에 대한 RoleBinding을 만드는 샘플 명령입니다.

kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser

kubeconfig에 추가

마지막 단계는 이 사용자를 kubeconfig 파일에 추가하는 것입니다.

먼저 새 자격 증명을 추가해야 합니다.

kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true

그런 다음 컨텍스트를 추가해야 합니다.

kubectl config set-context myuser --cluster=kubernetes --user=myuser

테스트하려면 컨텍스트를 myuser다음 으로 변경하십시오.

kubectl config use-context myuser

승인 또는 거부

제어 영역 자동 승인

kubernetes.io/kube-apiserver-client-kubeletkube-controller-manager 는 노드 자격 증명에 대한 CSR에 대한 다양한 권한을 권한 부여에 위임 하는 signerName이 있는 인증서에 대한 내장 승인자와 함께 제공됩니다 . kube-controller-manager는 인증서 승인을 위한 권한 부여를 확인하기 위해 API 서버에 SubjectAccessReview 리소스를 게시합니다.

다음을 사용하여 승인 또는 거부kubectl

kubectl certificate approveKubernetes 관리자(적절한 권한이 있음)는 및 kubectl certificate deny명령 을 사용하여 CertificateSigningRequests를 수동으로 승인(또는 거부)할 수 있습니다 .

kubectl로 CSR을 승인하려면:

kubectl certificate approve <certificate-signing-request-name>

마찬가지로 CSR을 거부하려면:

kubectl certificate deny <certificate-signing-request-name>

Kubernetes API를 사용한 승인 또는 거부

REST API 사용자는 승인할 CSR의 하위 리소스에 UPDATE 요청을 제출하여 approval CSR을 승인할 수 있습니다. 예를 들어 다음과 같이 작성할 수 있습니다. 운영자특정 종류의 CSR을 감시한 다음 업데이트를 보내 승인합니다.

승인 또는 거부 요청을 할 때 결정한 상태에 따라 Approved또는 Denied 상태 조건을 설정합니다.

ApprovedCSR 의 경우 :

`apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...status:
conditions:

• lastUpdateTime: "2020-02-08T11:37:35Z"
  lastTransitionTime: "2020-02-08T11:37:35Z"
  message: Approved by my custom approver controller
  reason: ApprovedByMyPolicy *# You can set this to any string*type: Approved`

DeniedCSR 의 경우 :

`apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...status:
conditions:

• lastUpdateTime: "2020-02-08T11:37:35Z"
  lastTransitionTime: "2020-02-08T11:37:35Z"
  message: Denied by my custom approver controller
  reason: DeniedByMyPolicy *# You can set this to any string*type: Denied`

status.conditions.reasonTitleCase를 사용하여 기계 친화적인 이유 코드 로 설정 하는 것이 일반적입니다. 이것은 규칙이지만 원하는 대로 설정할 수 있습니다. 사람이 사용하는 메모를 추가하려면 status.conditions.message필드를 사용하십시오.

서명

제어 평면 서명자

Kubernetes 제어 평면 은 kube-controller-manager의 일부로 각 Kubernetes 서명자 를 구현합니다.

참고: Kubernetes v1.18 이전에는 kube-controller-manager가 승인된 것으로 표시된 CSR에 서명했습니다.

참고: 이 spec.expirationSeconds필드는 Kubernetes v1.22에 추가되었습니다. 이전 버전의 Kubernetes는 이 필드를 사용하지 않습니다. v1.22 이전의 Kubernetes API 서버는 객체가 생성될 때 이 필드를 자동으로 삭제합니다.

API 기반 서명자

REST API 사용자는 서명할 CSR의 하위 리소스에 UPDATE 요청을 제출하여 status CSR에 서명할 수 있습니다.

이 요청의 일부로 status.certificate서명된 인증서를 포함하도록 필드를 설정해야 합니다. 이 필드에는 하나 이상의 PEM 인코딩 인증서가 포함됩니다.

모든 PEM 블록에는 "CERTIFICATE" 레이블이 있어야 하고 헤더가 포함되지 않으며 인코딩된 데이터는 RFC5280의 섹션 4에 설명된 대로 BER 인코딩된 ASN.1 인증서 구조여야 합니다.

인증서 내용 예시:

-----BEGIN CERTIFICATE-----
MIIDgjCCAmqgAwIBAgIUC1N1EJ4Qnsd322BhDPRwmg3b/oAwDQYJKoZIhvcNAQEL
BQAwXDELMAkGA1UEBhMCeHgxCjAIBgNVBAgMAXgxCjAIBgNVBAcMAXgxCjAIBgNV
BAoMAXgxCjAIBgNVBAsMAXgxCzAJBgNVBAMMAmNhMRAwDgYJKoZIhvcNAQkBFgF4
MB4XDTIwMDcwNjIyMDcwMFoXDTI1MDcwNTIyMDcwMFowNzEVMBMGA1UEChMMc3lz
dGVtOm5vZGVzMR4wHAYDVQQDExVzeXN0ZW06bm9kZToxMjcuMC4wLjEwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDne5X2eQ1JcLZkKvhzCR4Hxl9+ZmU3
+e1zfOywLdoQxrPi+o4hVsUH3q0y52BMa7u1yehHDRSaq9u62cmi5ekgXhXHzGmm
kmW5n0itRECv3SFsSm2DSghRKf0mm6iTYHWDHzUXKdm9lPPWoSOxoR5oqOsm3JEh
Q7Et13wrvTJqBMJo1GTwQuF+HYOku0NF/DLqbZIcpI08yQKyrBgYz2uO51/oNp8a
sTCsV4OUfyHhx2BBLUo4g4SptHFySTBwlpRWBnSjZPOhmN74JcpTLB4J5f4iEeA7
2QytZfADckG4wVkhH3C2EJUmRtFIBVirwDn39GXkSGlnvnMgF3uLZ6zNAgMBAAGj
YTBfMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMB
Af8EAjAAMB0GA1UdDgQWBBTREl2hW54lkQBDeVCcd2f2VSlB1DALBgNVHREEBDAC
ggAwDQYJKoZIhvcNAQELBQADggEBABpZjuIKTq8pCaX8dMEGPWtAykgLsTcD2jYr
L0/TCrqmuaaliUa42jQTt2OVsVP/L8ofFunj/KjpQU0bvKJPLMRKtmxbhXuQCQi1
qCRkp8o93mHvEz3mTUN+D1cfQ2fpsBENLnpS0F4G/JyY2Vrh19/X8+mImMEK5eOy
o0BMby7byUj98WmcUvNCiXbC6F45QTmkwEhMqWns0JZQY+/XeDhEcg+lJvz9Eyo2
aGgPsye1o3DpyXnyfJWAWMhOz7cikS5X2adesbgI86PhEHBXPIJ1v13ZdfCExmdd
M1fLPhLyR54fGaY+7/X8P9AZzPefAkwizeXwe9ii6/a08vWoiE4=
-----END CERTIFICATE-----

비 PEM 콘텐츠는 CERTIFICATE PEM 블록 전후에 나타날 수 있으며 RFC7468의 섹션 5.2에 설명된 대로 설명 텍스트를 허용하기 위해 검증되지 않습니다.

JSON 또는 YAML로 인코딩된 경우 이 필드는 base-64로 인코딩됩니다. 위의 예제 인증서가 포함된 CertificateSigningRequest는 다음과 같습니다.

`apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
...status:
certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..."`