Update administer-cluster in dev-1.21-ko.2
This commit is contained in:
seokho-son
parent
c47bc83e41
commit
9a7f807474
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -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의 생성을 방지할 수 있을 것이다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue