기본 지식
8482 단어 certificatetech
cert-manager란?
kubernetes 클러스터에서 SSL/TLS 인증서를 간단하게 처리하는 도구입니다.
인증서의 취득, 갱신, 사용이 간단해졌다.
공식 문서
이 글의 내용
이 글에서는 cert-Manager를 사용하면서 최소한 통제해야 할'증명서 발행·활용 프로세스'와'등장인물'만 간단히 정리했다.
증명서 주변에서는 사고가 나면 귀찮아서 만지고 싶지 않을 수도 있지만 기초 지식을 먼저 알고 싶은 것이 최초의 발판이다.
cert-manager v1.이어서 6.1의 이야기를 하겠습니다.
또한 Let's Encerypt를 Issuer의 프로세스로 설명하기 때문에 다른 Issuer Type에는 다른 내용이 있습니다.
인증서 발행 및 사용의 간단한 절차
우선 대략적인 절차를 하나 써라.
실제 설치 방법과 조작 등 상세한 내용은 공식 문서에 넘길 것이다.
Issuer 어셈블리를 생성합니다.Certificate 어셈블리를 생성합니다.Issuer, Certificate 구성 요소의 설정에 따라 지정한 인증서 발행인에게 지정한 영역의 인증서를 요청합니다.チャレンジ.チャレンジ가 완료되면 발행된 인증서와 키는 Secret 자원에 저장됩니다.인증서와 키가 저장된 시크릿은 참조
Ingress 등을 통해 인증서로 암호 통신을 할 수 있습니다.등장인물
cert-Manager는 인증서를 취득하고 이용할 때 관련 등장인물을 소개한다.
Issuer
Issuer 구성 요소는 Custom Resource Definition(CRD)에 의해 정의된 자원입니다.Issuer 구성 요소는 같은namespace에서만 발행할 수 있습니다Certificate.ClusterIssuer 구성 요소를 사용합니다.Certificate
여기 기사.에 통속적이고 알기 쉽게 썼다.
ACME Orders and Challenges
チャレンジ라고 불리는 메커니즘이다.チャレンジ을 완성하기 위해cert-Manager는 다음 두 개의 CRD를 가져옵니다.Order Challenge Order
チャレンジ는 실행 요청을 나타낸다.チャレンジ의 상세한 내용은 여기.이다.Challenge
표시
チャレンジ.Order 하나에 대해 여러 도메인Challenge을 생성합니다.Challenge 대기열에서 순서대로 처리합니다.チャレンジ 완성 후Challenge 자원이 Kubernetes 그룹에서 사라집니다.Ingress
Ingress에서 참고하고 사용합니다.Ingresscert-Manager가 CRD로 정의하는 리소스가 아닙니다.등장인물별 manfest 파일 샘플
위에서 말한 바와 같이 다음 세 가지 자원은 사용자가 manfest 파일을 제작하고 관리해야 한다.
Issuer Certificate Ingress 문서 견본
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: YOUR_ISSUER_NAME
spec:
acme:
email: "[email protected]"
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: lets-encrypt
solvers:
- dns01:
cloudDNS:
project: example-com
serviceAccountSecretRef:
name: prod-clouddns-svc-acct-secret
key: service-account.json
Issuer의 manfest 중 가장 중요한 것은 metadata.name와spec以下이다.metadata.name가 바로 이 자원의 명칭이다.중요한 것은 다른 자원에서 이 자원을 인용하는 것이다.spec以下 타입에 따라 다릅니다.이번에는 Let's Encerypt를 사용하는 전제조건이기 때문에Issuer.이 manfest는 Staging 환경의 Let's Encerypt 서버에 대한 실행
spec.acme입니다. GCP의 클라우드 DNS를 사용하세요. DNS01チャレンジ라는 GCP 프로젝트의 클라우드 DNS를 사용하기 위해example-com이 시크릿 자원에 서비스 계정의 신용도를 놓았습니다.다른 IssuerType 또는 ACME를 사용하여 다른 설정을 선택할 때는 공식 문서를 참조하십시오.
문서 견본
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: YOUR_CERTIFICATE_NAME
spec:
secretName: YOUR_SECRET_NAME
dnsNames:
- example.com
issuerRef:
name: YOUR_ISSUER_NAME
kind: Issuer
prod-clouddns-svc-acct-secret 구성 요소의 manfest 파일에 Certificate,secretName,dnsNames의 필드가 존재합니다.issuerRef에서 지정한 dnsNames에서 지정한 issuerRef에서 Issuer에서 지정한 영역의 인증서를 받습니다.secretName Kubernetes의 Secret 자원 이름을 지정합니다.이 Secret은 실제 키와 인증서를 저장합니다.manfest 파일을 설정하면
example.com 인증서는 YOUR_ISSUER_NAME 라는 Issueer 에서 가져오고 인증서와 키는 YOUR_SECRET_NAME 라는 Secret 자원에 저장됩니다.실제 시크릿에 저장된 예는 다음과 같습니다.
$ kubectl get secret ${YOUR_SECRET_NAME}
apiVersion: v1
kind: Secret
data:
tls.crt: LS0tLaa.....
tls.key: LS0tLOU....
creationTimestamp: "2022-00-00T00:00:00Z"
labels:
certmanager.k8s.io/certificate-name: YOUR_SECRET_NAME
name: YOUR_SECRET_NAME
namespace: YOUR_NAMESPACE_NAME
...
...
data.tls.crt는 인증서 값을 포함하고 data.tls.key는 키 값을 포함한다.이 값을 사용하여 암호 통신을 실현합니다.
참고로 실제 인증서의 값은 Secret에만 존재합니다.
헷갈리기 쉽습니다.
Certificate 자원에 인증서 값이 존재하지 않습니다.대신 인증서 실효, 예정일 갱신 등의 정보를 포함한다.
$ kubectl get Certificate ${YOUR_CERTIFICATE_NAME}
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
creationTimestamp: "2022-01-13T12:19:50Z"
generation: 1
name: YOUR_CERTIFICATE_NAME
namespace: YOUR_NAMESPACE_NAME
spec:
commonName: example.com
dnsNames:
- example.com
issuerRef:
kind: Issuer
name: YOUR_ISSUER_NAME
secretName: YOUR_SECRET_NAME
status:
conditions:
- lastTransitionTime: "2022-01-13T12:19:50Z" # 2022/1/13に作成
message: Certificate is up to date and has not expired
observedGeneration: 1
reason: Ready
status: "True"
type: Ready
notAfter: "2022-04-13T11:21:25Z" # 90日後の2022/4/13に失効
notBefore: "2022-01-13T11:21:26Z"
renewalTime: "2022-03-14T11:21:25Z" # 60日後の2022/3/14に更新予定
revision: 1
문서 견본
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
cert-manager.io/issuer: YOUR_ISSUER_NAME
name: YOUR_INGRESS_NAME
namespace: YOUR_INGRESS_NAME
spec:
rules:
- host: example.com
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: YOUR_SERVICE_NAME
port:
number: 80
tls:
- hosts:
- example.com
secretName: YOUR_SECRET_NAME
tls.hosts[0].secretName에 인증서와 키를 가진 시크릿의 이름을 입력함으로써 Ingress는 인증서를 참조하여 암호 통신을 실현한다.즉
Certificate의manfest 내spec.secretName값과 같으면 OK라는 것이다.총결산
간단하게 말하면 manfest 파일의 샘플을 포함하여cert-관리자가 인증서를 취득하고 사용하는 절차를 소개했다.
cert-Manager의 공식 문서가 비교적 충실해서 나는 배울 만하다고 생각한다.
관심 있는 사람이 자세히 읽어보면 재미있을 거예요.
Reference
이 문제에 관하여(기본 지식), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/masaaania/articles/e54119948bbaa2텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
