Update administer-cluster in dev-1.21-ko.2

content/ko/docs/tasks/administer-cluster/declare-network-policy.md

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 네트워크 폴리시(Network Policy) 선언하기
 min-kubernetes-server-version: v1.8
 content_type: task
@@ -13,8 +16,9 @@ content_type: task
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
-네트워크 폴리시를 지원하는 네트워크 제공자를 구성하였는지 확인해야 한다. 다음과 같이 네트워크폴리시를 제공하는 많은 네트워크 제공자들이 있다.
+네트워크 폴리시를 지원하는 네트워크 제공자를 구성하였는지 확인해야 한다. 다음과 같이 네트워크폴리시를 지원하는 많은 네트워크 제공자들이 있다.
 
+* [Antrea](/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy/)
 * [캘리코(Calico)](/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/)
 * [실리움(Cilium)](/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
 * [Kube-router](/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)

content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

@@ -1,4 +1,6 @@
 ---
+
+
 title: kubeadm을 사용한 인증서 관리
 content_type: task
 weight: 10
@@ -190,11 +192,13 @@ CSR과 함께 제공되는 개인 키가 모두 출력된다.
 `kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다.
 
 CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다.
-인증서를 발행할 때 [올바른 인증서 용도](/ko/docs/setup/best-practices/certificates/#모든-인증서)를 지정하는 것은 CA의 책임이다.
+인증서를 발행할 때 [올바른 인증서 용도](/ko/docs/setup/best-practices/certificates/#모든-인증서)를
+지정하는 것은 CA의 책임이다.
 
 * `openssl` 의 경우
   [`openssl ca` 명령](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)으로 수행한다.
-* `cfssl` 의 경우 [설정 파일에 용도](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)를 지정한다.
+* `cfssl` 의 경우
+  [설정 파일에 용도](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)를 지정한다.
 
 선호하는 방법으로 인증서에 서명한 후, 인증서와 개인 키를 PKI 디렉터리(기본적으로 `/etc/kubernetes/pki`)에 복사해야 한다.
 
@@ -203,3 +207,71 @@ CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지
 Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다.
 
 CA의 수동 순환이나 교체에 대한 보다 상세한 정보는 [CA 인증서 수동 순환](/docs/tasks/tls/manual-rotation-of-ca-certificates/) 문서를 참조한다.
+
+## 서명된 kubelet 인증서 활성화하기 {#kubelet-serving-certs}
+
+기본적으로 kubeadm에 의해서 배포된 kubelet 인증서는 자가 서명된(self-signed) 것이다.
+이것은 [metrics-server](https://github.com/kubernetes-sigs/metrics-server)와
+같은 외부 서비스의 kubelet에 대한 연결은
+TLS로 보안되지 않음을 의미한다.
+
+제대로 서명된 인증서를 얻기 위해서 신규 kubeadm 클러스터의 kubelet을 구성하려면
+다음의 최소 구성을 `kubeadm init` 에 전달해야 한다.
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+---
+apiVersion: kubelet.config.k8s.io/v1beta1
+kind: KubeletConfiguration
+serverTLSBootstrap: true
+```
+
+만약 이미 클러스터를 생성했다면 다음을 따라 이를 조정해야 한다.
+ - `kube-system` 네임스페이스에서 `kubelet-config-{{< skew latestVersion >}}` 컨피그맵을 찾아서 수정한다.
+해당 컨피그맵에는 `config` 키가
+[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
+문서를 값으로 가진다. `serverTLSBootstrap: true` 가 되도록 KubeletConfiguration 문서를 수정한다.
+- 각 노드에서, `serverTLSBootstrap: true` 필드를 `/var/lib/kubelet/config.yaml` 에 추가한다.
+그리고 `systemctl restart kubelet` 로 kubelet을 재시작한다.
+
+`serverTLSBootstrap: true` 필드는 kubelet 인증서를 이용한 부트스트랩을
+`certificates.k8s.io` API에 요청함으로써 활성화할 것이다. 한 가지 알려진 제약은
+이 인증서들에 대한 CSR(인증서 서명 요청)들이 kube-controller-manager -
+[`kubernetes.io/kubelet-serving`](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)의
+기본 서명자(default signer)에 의해서 자동으로 승인될 수 없다는 점이다.
+이것은 사용자나 제 3의 컨트롤러의 액션을 필요로 할 것이다.
+
+이 CSR들은 다음을 통해 볼 수 있다.
+
+```shell
+kubectl get csr
+NAME        AGE     SIGNERNAME                        REQUESTOR                      CONDITION
+csr-9wvgt   112s    kubernetes.io/kubelet-serving     system:node:worker-1           Pending
+csr-lz97v   1m58s   kubernetes.io/kubelet-serving     system:node:control-plane-1    Pending
+```
+
+이를 승인하기 위해서는 다음을 수행한다.
+```shell
+kubectl certificate approve <CSR-name>
+```
+
+기본적으로, 이 인증서는 1년 후에 만기될 것이다. Kubeadm은
+`KubeletConfiguration` 필드의 `rotateCertificates` 를 `true` 로 설정한다. 이것은 만기가
+다가오면 인증서를 위한 신규 CSR 세트가 생성되는 것을 의미하며,
+해당 순환(rotation)을 완료하기 위해서는 승인이 되어야 한다는 것을 의미한다. 더 상세한 이해를 위해서는
+[인증서 순환](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation)를 확인한다.
+
+만약 이 CSR들의 자동 승인을 위한 솔루션을 찾고 있다면 클라우드 제공자와
+연락하여 대역 외 메커니즘(out of band mechanism)을 통해 노드의 신분을 검증할 수 있는
+CSR 서명자를 가지고 있는지 문의하는 것을 추천한다.
+
+{{% thirdparty-content %}}
+
+제 3 자 커스텀 컨트롤러도 사용될 수 있다.
+- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp)
+
+이러한 컨트롤러는 CSR의 CommonName과 요청된 IPs 및 도메인 네임을
+모두 검증하지 않는 한, 보안이 되는 메커니즘이 아니다. 이것을 통해 악의적 행위자가
+kubelet 인증서(클라이언트 인증)를 사용하여 아무 IP나 도메인 네임에 대해 인증서를
+요청하는 CSR의 생성을 방지할 수 있을 것이다.