[ko] Update outdated files in dev-1.24-ko.1 M115-M138
This commit is contained in:
Jihoon Seo
@@ -17,7 +17,7 @@ content_type: task
|
||||
유사한 프로토콜을 사용한다.
|
||||
|
||||
{{< note >}}
|
||||
`certificates.k8s.io` API를 사용하여 생성된 인증서는 전용 CA로 서명된다.
|
||||
`certificates.k8s.io` API를 사용하여 생성된 인증서는 [전용 CA](#a-note-to-cluster-administrators)로 서명된다.
|
||||
이러한 목적을 위해 클러스터 루트 CA를 사용하도록 클러스터를
|
||||
구성할 수 있지만, 절대 이에 의존해서는 안된다.
|
||||
해당 인증서가 클러스터 루트 CA에 대해 유효성을 검사한다고 가정하면 안된다.
|
||||
@@ -29,24 +29,38 @@ content_type: task
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
`cfssl` 도구가 필요하다.
|
||||
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases)에서 `cfssl`을 다운로드할 수 있다.
|
||||
|
||||
이 페이지의 일부 단계에서 `jq` 도구를 사용한다.
|
||||
`jq`가 없다면, 사용 중인 운영 체제의 소프트웨어 소스를 통해 설치하거나,
|
||||
[https://stedolan.github.io/jq/](https://stedolan.github.io/jq/)에서 받을 수 있다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 클러스터에서 TLS 신뢰
|
||||
|
||||
파드로 실행되는 애플리케이션에서 사용자 정의 CA를 신뢰하려면
|
||||
파드로 실행되는 애플리케이션에서 [사용자 정의 CA](#a-note-to-cluster-administrators)를 신뢰하려면
|
||||
일반적으로 몇 가지 추가 애플리케이션 구성이 필요하다.
|
||||
TLS 클라이언트 또는 서버가 신뢰하는 CA 인증서 목록에
|
||||
CA 인증서 번들을 추가해야 한다.
|
||||
예를 들어 인증서 체인을 파싱하고, 파싱된 인증서를 [`tls.Config`](https://godoc.org/crypto/tls#Config) 구조체의
|
||||
예를 들어 인증서 체인을 파싱하고, 파싱된 인증서를 [`tls.Config`](https://pkg.go.dev/crypto/tls#Config) 구조체의
|
||||
`RootCAs` 필드에 추가하여, golang TLS 구성으로 이를 수행할 수 있다.
|
||||
|
||||
CA 인증서를 파드에서 사용할 수 있는
|
||||
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap)으로
|
||||
배포할 수 있다.
|
||||
{{< note >}}
|
||||
사용자 정의 CA 인증서가
|
||||
파일시스템(`kube-root-ca.crt` 컨피그맵 내)에 포함될 수 있더라도,
|
||||
이 인증서 권한을 내부 쿠버네티스 엔드포인트 검증 용도 외에는 사용하지 말아야 한다.
|
||||
내부 쿠버네티스 엔드포인트에 대한 하나의 예시는
|
||||
기본 네임스페이스에 있는 `kubernetes`라는 서비스이다.
|
||||
|
||||
당신의 워크로드를 위한 사용자 정의 인증서 권한을 사용하고 싶다면,
|
||||
이 CA를 별도로 생성하고, 파드가 읽을 수 있는
|
||||
[컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/) 형태로
|
||||
해당 CA 인증서를 배포해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 인증서 요청
|
||||
|
||||
@@ -57,11 +71,6 @@ TLS 인증서를 생성하는 방법을 보여준다.
|
||||
이 튜토리얼에서는 CFSSL을 사용한다. [여기를 클릭](https://blog.cloudflare.com/introducing-cfssl/)하여 Cloudflare의 PKI 및 TLS 툴킷을 자세히 알아본다.
|
||||
{{< /note >}}
|
||||
|
||||
## CFSSL 다운로드 및 설치
|
||||
|
||||
이 예제에 사용된 cfssl 도구는
|
||||
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases)에서 다운로드 할 수 있다.
|
||||
|
||||
## 인증서 서명 요청 (CSR) 생성
|
||||
|
||||
다음 명령을 실행하여 개인 키 및 인증서 서명 요청(또는 CSR)을
|
||||
@@ -98,14 +107,14 @@ EOF
|
||||
```
|
||||
|
||||
이 명령은 두 개의 파일을 생성한다. PEM으로
|
||||
인코딩된 [pkcs#10](https://tools.ietf.org/html/rfc2986)
|
||||
인코딩된 [PKCS#10](https://tools.ietf.org/html/rfc2986)
|
||||
인증 요청이 포함된 `server.csr`과 생성할 인증서 키를 PEM 인코딩한 값이
|
||||
포함된 `server-key.pem`을 생성한다.
|
||||
|
||||
## 쿠버네티스 API로 보낼 인증서 서명 요청 객체 만들기
|
||||
|
||||
CSR yaml blob을 생성하고 다음 명령을 실행하여
|
||||
apiserver로 보낸다.
|
||||
CSR 매니페스트(YAML 형태)를 생성하고, API 서버로 전송한다.
|
||||
다음 명령어를 실행하여 수행할 수 있다.
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl apply -f -
|
||||
@@ -157,7 +166,7 @@ Subject Alternative Names:
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
## 인증서 서명 요청 승인 받기
|
||||
## 인증서 서명 요청 승인 받기 {#get-the-certificate-signing-request-approved}
|
||||
|
||||
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 승인은
|
||||
자동화된 승인 프로세스 또는 클러스터 관리자의 일회성 승인으로 수행된다.
|
||||
@@ -186,7 +195,7 @@ my-svc.my-namespace 10m example.com/serving yourname@example.com <none>
|
||||
이는 즉 인증서 요청이 승인되었으며
|
||||
요청받은 서명자의 서명을 기다리고 있음을 나타낸다.
|
||||
|
||||
## 인증서 서명 요청에 서명하기
|
||||
## 인증서 서명 요청에 서명하기 {#sign-the-certificate-signing-request}
|
||||
|
||||
다음으로, 인증서 서명자로서, 인증서를 발급하고, 이를 API에 업로드할 것이다.
|
||||
|
||||
@@ -196,7 +205,9 @@ my-svc.my-namespace 10m example.com/serving yourname@example.com <none>
|
||||
|
||||
### 인증 기관 생성하기
|
||||
|
||||
먼저: 다음을 실행하여 서명 인증서를 생성한다.
|
||||
새 인증서의 디지털 서명에 제공할 인증 기관이 필요하다.
|
||||
|
||||
먼저, 다음을 실행하여 서명 인증서를 생성한다.
|
||||
|
||||
```shell
|
||||
cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
|
||||
@@ -256,16 +267,19 @@ kubectl get csr my-svc.my-namespace -o json | \
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
위의 명령에서 `.status.certificate` 필드에 base64로 인코딩된 내용을 채우기 위해 [jq](https://stedolan.github.io/jq/) 명령줄 도구를 사용하였다.
|
||||
`jq`가 없다면, JSON 출력을 파일에 저장하고, 해당 필드를 수동으로 채우고, 그 결과 파일을 업로드할 수도 있다.
|
||||
위의 명령에서 `.status.certificate` 필드에 base64로 인코딩된 내용을 채우기 위해
|
||||
[`jq`](https://stedolan.github.io/jq/) 명령줄 도구를 사용하였다.
|
||||
`jq`가 없다면, JSON 출력을 파일에 저장하고,
|
||||
해당 필드를 수동으로 채우고, 그 결과 파일을 업로드할 수도 있다.
|
||||
{{< /note >}}
|
||||
|
||||
인증서 서명 요청이 승인되고 서명된 인증서가 업로드되면 다음과 같은 출력을 볼 수 있을 것이다.
|
||||
인증서 서명 요청이 승인되고 서명된 인증서가 업로드되면 다음을 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl get csr
|
||||
```
|
||||
|
||||
출력은 다음과 같을 것이다.
|
||||
```none
|
||||
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
|
||||
my-svc.my-namespace 20m example.com/serving yourname@example.com <none> Approved,Issued
|
||||
@@ -281,37 +295,48 @@ kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
|
||||
| base64 --decode > server.crt
|
||||
```
|
||||
|
||||
이제 `server.crt` 및 `server-key.pem`의 내용으로 시크릿을 생성하고 파드에 마운트하여
|
||||
HTTPS 서버를 시작하는 데 필요한 키페어로 사용할 수 있다.
|
||||
이제 `server.crt` 및 `server-key.pem`의 내용으로
|
||||
{{< glossary_tooltip text="시크릿" term_id="secret" >}}을 생성할 수 있으며,
|
||||
이 시크릿은 추후 파드에 마운트할 수 있다(예를 들어,
|
||||
HTTPS를 제공하는 웹서버에 사용).
|
||||
|
||||
```shell
|
||||
kubectl create secret tls server --cert server.crt --key server-key.pem
|
||||
kubectl create secret tls server --cert server.crt --key server-key.pem
|
||||
```
|
||||
|
||||
```none
|
||||
secret/server created
|
||||
```
|
||||
|
||||
마지막으로, `ca.pem`의 내용으로 컨피그맵을 생성하여
|
||||
마지막으로, `ca.pem`의 내용으로 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 생성하여
|
||||
제공(serving) 인증서 검증에 필요한 신뢰 루트로 사용할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
|
||||
kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
|
||||
```
|
||||
|
||||
```none
|
||||
configmap/example-serving-ca created
|
||||
```
|
||||
|
||||
## 인증서 서명 요청 승인
|
||||
## CertificateSigningRequest 승인 {#approving-certificate-signing-requests}
|
||||
|
||||
(적절한 권한이 있는) 쿠버네티스 관리자는
|
||||
`kubectl certificate approve` 과 `kubectl certificate deny`
|
||||
명령을 사용하여 인증서 서명 요청을 수동으로 승인 (또는 거부) 할 수 있다.
|
||||
명령을 사용하여 CertificateSigningRequest을 수동으로 승인 (또는 거부) 할 수 있다.
|
||||
그러나 이 API를 많이 사용한다면,
|
||||
자동화된 인증서 컨트롤러 작성을 고려할 수 있다.
|
||||
|
||||
위와 같이 kubectl을 사용하는 시스템이든 사람이든, 승인자의 역할은
|
||||
{{< caution >}}
|
||||
CSR을 승인할 수 있는 권한이 있다는 것은 당신의 환경에서 누가 누구를 신뢰할 수 있는지를 결정할 수 있다는 것이다.
|
||||
CSR을 승인할 수 있는 권한은 넓게/가볍게 부여되지 않아야 한다.
|
||||
|
||||
`approve` 권한을 부여하기 전에,
|
||||
승인자에게 할당되는 검증 요구 사항 **및** 특정 인증서 발급에 따른 영향을
|
||||
모두 확실히 이해하고 있는지 확인해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
위와 같이 kubectl을 사용하는 시스템이든 사람이든, _승인자_ 의 역할은
|
||||
CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다.
|
||||
|
||||
1. CSR은 CSR에 서명하는 데 사용되는 개인 키를 제어하는 것이다. 이는
|
||||
@@ -326,17 +351,13 @@ CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다
|
||||
이 두 가지 요구 사항이 충족되는 경우에만, 승인자가 CSR을 승인하고
|
||||
그렇지 않으면 CSR을 거부해야 한다.
|
||||
|
||||
## 승인 허가에 대한 경고문
|
||||
인증서 승인 및 접근 제어에 대한 추가 정보를 보려면,
|
||||
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 레퍼런스 페이지를
|
||||
참조한다.
|
||||
|
||||
CSR을 승인하는 능력은 환경 내에서 누구를 신뢰하는지 결정한다. CSR 승인
|
||||
능력은 광범위하거나 가볍게 부여해서는 안된다. 이 권한을
|
||||
부여하기 전에 이전 섹션에서 언급한
|
||||
요청의 요구 사항과 특정 인증서 발급의 영향을
|
||||
완전히 이해해야 한다.
|
||||
## 서명을 제공하도록 클러스터 구성하기 {#a-note-to-cluster-administrators}
|
||||
|
||||
## 클러스터 관리자를 위한 참고 사항
|
||||
|
||||
이 가이드에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스
|
||||
이 페이지에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스
|
||||
컨트롤러 관리자는 서명자의 기본 구현을 제공한다. 이를
|
||||
활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 `--cluster-signing-cert-file` 와
|
||||
`--cluster-signing-key-file` 매개 변수를
|
||||
|
||||
Reference in New Issue
Block a user