시골쥐의 공부생활

웹 페이지를 개설했다면, 그리고 외부에서 접근가능하려면 어떻게 해야할까?

이를 위해 많은 분들이 Service와 Ingress를 혼동한다. 그래서 이에 대해 짧게 알아보도록 하자.

NodePort type의 Service를 통해 포트를 정의해줘서 외부로부터 접근이 가능하게 만들 수 있다.

그리고, 포트를 외우기 귀찮으니(원래는 http://my-online-store.com:38080으로로 접근)

proxy server를 이용함으로써 URL을 통해 접근 가능하게 한다.

만약 GCP등의 Cloud platform을 사용한다면 LoadBalancer Type의 service를 사용하면 된다.

그럼 K8s가 알아서 포트, 외부 ip등을 다 할당해준다.

자, 그런데 비즈니스가 잘 되어서 /watch라는 또 다른 app을 만든다고 치자.

그럼 기존 my-online-store.com은 my-online-store.com/wear로 바꾸어야할 것이다.

그럼 동일한 클러스터 내 오른쪽 노란색 표기와 같이 새로운 인스턴스들을 만든다.

그럼, wear app에 접근 또는 video 앱에 각각 접근하기 위해 어떻게 해야할까?

가장 상단에 새로운 service를 만들어서 이 두개 app에 대한 정의를 해야하고, SSL enable도 시켜야 한다.

그런데 이건, app level과 다른 level이다.

그런데, app이 더 늘어날 경우?

계속 파일을 수정해줘야하고 SSL도 처리해야하고, 경로와 포트등을 계속 만들어줘야 한다.

그래서 Ingress라는 개념이 나왔다.

Ingress는 K8s에 built-in된 7계층 LoadBalancer로,

하나의 외부 URL을 이용해서 클러스터 내 다른 서비스로 라우팅을 시켜줄 수 있고, SSL Security또한 실행해줄 수 있다.

하지만, 이 또한 외부에서 클러스터로 접근하기 위해

node port 또는 cloud native LB를 사용해서 외부로 노출시켜줘야 한다.

다만, 이건 단 한번만 하면 된다. 

1. Deploy = Ingress controller

Ingress를 위한 solution으로는 nginx, haproxy, traefik 등을 사용하면 된다.

이렇게 deploy하게되는 솔루션들을 ingress controller라고 부르고,

2. Configure = Ingress resources

설정하는 rule들을 ingress resource라고 부른다.

이건 기존 우리가 생성했던 pod deploy처럼 definition file을 이용해서 생성된다.

그런데, ingress controller는 defualt로 built-in 되어있지 않다. 

그래서 이걸 무조건 deploy 해줘야 하는데, 어떤 걸 deploy 해줘야할까?

위와 같이 많은 종류의 사용 가능한 솔루션이 있다.

이 강의에서는 nginx를 예시로 사용하고 있고, 이건 기존에 사용하던 LB나 nginx 서버와는 다르다.

Ingress controller에서 LB 컴포넌트는 단지 일부일뿐이고, K8s 클러스터를 모니터링 할 수 있는 기능이 포함되어 있다.

Controller는 다른 deployment와 동일한 방식으로 deploy 되는데, definition file을 한번 확인해보자.

nginx program은 /nginx-ingress-controller라는 경로에 저장되어 있는데, 

keep-alive threshold, ssl setting, session timeout 등을 설정하기 위해 별도의 ConfigMap을 만든다.

그래서 configmap에 대한 정의 또한 args에 포함한다.

그리고, pod와 pod의 namespace 또한 env로 포함해줘야하고,

ingress controller에 의해 사용되는 ports 또한 추가한다.

그리고, ingress controller를 외부 세상에 노출하기 위해 service가 필요하다.

그래서 NodePort 타입의 service를 생성하고, label-selector를 이용해서 deployment와 링크시킨다.

그리고, 아까 언급했듯 ingress는 k8s 클러스터를 모니터링하는 추가적인 기능들을 갖고 있다.

그래서 어떤 설정이 변경되었을 때, 그것들을 nginx 서버에 설정할 수 있는데, 이를 위해 service account가 필요하다.

이 service account에는 맞는 퍼미션이 필요한데, 그를 위해 roles과 roles binding이 필요하다.

즉, 정리하자면

ingress를 위해서는 최소한으로 Deployment file, service file, configmap, Auth(ServiceAccount)가 필요하다.

ingress resource는 ingress controller에 적용되는 rules과 configurations들의 세트인데, 

첫 번째 그림과 같이 모든 incomming traffic에 대해 single application으로 route할 수도 있고, 

두 번째 그림과 같이 URL을 기반으로 다른 app들로 라우팅을 분배할 수도 있다. 

그럼 이것들을 어떻게 설정하는지 알아보자.

ingress resource는 위의 오른쪽과 같이 파일을 정의해주는데, pod에게 direct로 가는 게 아니라, service로 보내준다.

그리고, 다른 조건에 따라 traffic을 분리하고 싶을 때 rules을 사용할 수도 있는데,

위와 같이 www.my-online-store.com // www.wear.my-online-store.com/ 등으로 분리할 수 있다.

아래에서 하나씩 설정을 확인해보자.

위와 같이, 각 호스트의 top level로부터 rule을 생성할 수도 있고,

URL을 기반으로 라우팅 패스를 다르게 설정할 수도 있다. 

어떻게 설정할까?

처음엔 Ingress-wear.yaml를 사용했지만,

지금은 두 개의 app으로 나뉘므로, ingress-wear-watch.yaml 파일에서 각각의 path와 service를 정의해줘야 한다. 

이후 yaml파일을 apply로 생성하면, 위와 같이 ingress를 조회해볼 수 있다.

2가지 path가 생긴 것을 확인할 수 있는데, 위의 Default backend는 무엇일까?

유저가 접근을 시도하는 URL이 없을 때(어떤 Rule도 match되지 않을 때) 보여주는 page를 정의하는 것이다.

위의 oops 404 페이지처럼 말이다.

자, 그럼 3번째 설정 타입으로는 domain name 또는 host name을 이용하는 것을 알아보자.

이전 설정에선 host를 정의하지 않았는데, host를 정의하지 않으면

hostname matching 없이 특정 rule에 따라 incoming traffic이 허용된다.

이전에 만든 것과 비교해보면(왼쪽), rule에 hostname이 추가되었을 뿐이다. (오른쪽)

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

pod/container가 생성된 후, 그 안에 있는 data는 pod/container가 삭제되면 함께 삭제된다.

그래서, 이런 데이터들을 영구적으로 보관하기 위해 Volume이라는 개념이 나온다.

single node라면 위와 같이 pod-definition에 'volumemount', 'volumes'로

node 내에 있는 /data directory에 저장한다고 정의할 수 있다.

그런데, multi-Node가 된다면 이 방법은 점점 더 복잡해질 것이다.

그래서 AWS, cephFS와 같은 Storage를 사용한다.

PV, PVC를 알아보자.

위와같이 POD별로 각 Storage를 설정하면 복잡해지고, 하나가 수정될 때마다 전체를 수정시켜야하는 귀찮음이 있다.

그래서 이를 중앙에서 관리하기 위한 solution으로 PV라는 Volume이 나온다.

PV: storage volumes의 wide pool

A persistent volume is a cluster wide pool of storage volumes configured by an administrator to be used

by users deploying applications on the Cluster.

PVC: User가 pv를 할당받기 위해 생성하는 instance

The users can now select storage from this pool using persistent volume claims.

administrator는 PV를 생성하고, user는 PV를 사용하기 위해 PVC를 생성한다.

PV를 생성해보자. 

간단하다, 위와 같이 Yaml 파일을 작성한다.

그러면 PV와 PVC간 Binding 작업이 이루어지는데, 보통 capa, access mode등이 거의 유사한 것끼리 1:1 binding이 된다.

혹시 특정한 PV, PVC를 쓰고 싶다면 labels/selector를 통해 설정할 수 있다.

만약 pvc에 맞는 pv가 없으면, pvc는 pending 상태가 된다.

pvc를 생성해보자.

pv와 거의 동일하며 storage size를 맞춰주자.

그리고 pvc를 삭제할 수도 있는데, pvc가 삭제되었을 때 PV가 어떻게 될지 설정할 수도 있다.

- Retain (admin이 수동으로 삭제할 때까지 갖고있기), Delete(삭제됨과 동시에 삭제), Recycle(다른데서 사용)

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

모든 pod끼리는 서로 연결이 되어있다.

그런데, 일부 구간(ex. web Pod - DB Pod)은 direct로 연결되지 않길 바랄 수도 있다. (security 이슈 등으로 인해)

그럴 때, Network Policy 라는 것을 사용한다.

Ingress traffic을 3306, API Pod에게만 받는 것이다.

이때, 예전에 배웠던 Selector, labels 인스턴스가 다시 나온다.

NetworkPolicy라는 yaml파일을 만든 뒤, spec 아래 부분에 오른쪽의 두 블럭을 붙여준다.

예를 들어 이렇게.

spec:

  podselector:

    matchlabels:

      role: db

  policyTypes:

  - Ingress

  Ingress:

  - from:

    - podSelector:

        matchLabels:

          name: api-pod

  ports:

  - protocol: TCP

    port: 3306

그럼 조금 더 조건을 추가해보자.

pod는 api-pod 에서만 들어오도록 하고, namespace는 prod에 있는 것만,

ip는 192.168.5.10/32로부터 오는 것만 허용하도록 하자.

이 경우, '-'를 사용할 경우, 별개의 룰이 되어 &&조건이 아닌 || 조건이 된다.

따라서, api pod이거나, prod namespace 안에 있거나, 192.168.5.10/32로부터 오면 허용한다는 뜻이다.

만약 &&조건을 주고 싶으면, '-'를 없애면 된다.

그리고, egress도 동시에 추가할 수 있다.

egress도 engress와 동일하되, egress는 outgoing 하는 traffic이므로 'to' 옵션을 사용한다.

network policy에 대한 조회는 아래 커멘드로 확인할 수 있다.

# kubectl get netpol [policy name]

# kubectl describe networkpol [policy name]

끝-

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

이전 강의까지, 우리는 user에 대한 role binding을 알아보았고, namespace도 지정했다.

즉, role binding은 namespace 내에 생성된다.(만약 namespace가 명시되지 않았다면 default namespace 내에 생성)

그런데, Node는 namespace에 종속될 수 있을까?

아니다. 즉, resources들은 namespaced or cluster scope으로 구분된다.

그래서 이번 강의에서는 cluster role / cluster binding에 대해 알아본다.

cluster scope에서는 namespaced에서 정의되어 있지 않은 것들을 정의한다.

그 중에, user에서 권한을 주기위해 사용했던 roles, rolebindings 파일은, 

cluster scope에서 clusterroles, clusterrolebindings 파일이 된다.

cluster role/binding은 기존 namespaced가 특정 namespaced에 속한 resource만 관리된 것과 달리,

여러 cluster내에 걸쳐있는 namespace또한 관리할 수 있다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

Authorization이 왜 필요할까?

클러스터는 다양한 clients들이 함께 사용하는데, 각자의 권한에 따라 기능을 제한하기 위함이다.

Authorization Mechanisms은 크게 4가지가 있는데, 하나씩 알아보자.

- Node Authorizer: named/pods system node내에서 발생하는 요청들은 Node Authrrizer에 의해 처리된다.

권한들은 kubelet에 의해 요구되기 때문에, cluster 내에서 일어난다.

external access to API

유저마다 권한이 다른데, 이걸 하나씩 직접 policy 파일에 등록/수정해야한다.

사람이 많아질수록 관리가 어려워지는데, 이를 위해 RBAC가 나왔다.

RBAC(Role Base Access Control):

유저마다 각각 policy를 만들지 않고, Developer, Security와 같은 Role을 만들어서 유저들을 해당 role에 associate한다.

이렇게 하면, role에서 수정된 내용들이 각 user에도 모두 적용되어 관리가 쉬워진다.

opensource를 쓰고 싶다면, open Policy Agent를 쓰면 된다.

open policy agent는 3rd party tool로 admission control & authorization을 도와준다.

남은 메커니즘으로 2가지가 더 있는데, AlwaysAllow와 Always Deny로 조건없이 항상 허용/거절하는 것이다.

그럼 이런 메카니즘들을 어디에 설정할까?

kube-apiserver에 설정된다. 만약 아무 값도 설정하지 않는다면, AlwaysAllow가 default 값이 된다.

그럼, 여러 개의 모드가 작성되어 있으면?

작성된 순서에 따라 체크를 하고, 각 모드에서 관련된 것이 없다면 다음 모드로 체크한다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

이전 강의들에서 계속 kubeapi server와 통신했다.

version을 보기 위해서는 왼쪽과 같이 조회할 수 있고, pod의 lists들을 얻기 위해서는 오른쪽과 같이 조회할 수도 있다.

여기서 말하는 /version, /api 들이 API Group이다.

실제로 api group들은 위와 같이 다양한데, 클러스터 functionality와 관련있는 /api, /apis에 대해 알아본다.

/api는 core server이고  /apis는 named server인데 아래에서 하나씩 알아보자.

core group인 /api는 all core functionality가 존재하는 곳으로 namespace, pods, nodes들이 정의되어 있다.

named group인 /apis는 더 정교한 정보들이 저장되어 있고, new feature들이 available 해진다.

크게 API Groups으로 나누고, 그 아래에서 Resource, Verbs 등으로 한 번 더 나뉜다.

All resources in Kubernetes are grouped into different api groups. At the top level you have core api group and named api group. Under the named api group You have one for each section under this API group.

You have the different resources and each resource has a set of associated actions known as verbs in

the next section on authorization.

실제로 k8s에서 해당 api group들을 조회해본다.

# curl http://localhost:6443 -k   // available한 api group listup

# curl http://localhost:6443/apis -k | grep "name" // 지원되는 all resource grp

그런데, 실제로 api version을 아래와 같이 정확하게 입력하지 않고, 위와 같이 -k로 입력하면 forbidden이 발생한다.

그런데 실제로 어떻게 api verison값들을 저렇게 다 써줄 수 있을까? (복잡한데 말이다.)

그래서 kubectl Proxy를 사용한다.

먼저 kubectl proxy에 접속한 후, curl 명령어를 통해 Kube ApiServer에 접근하면 된다.

단, 여기서 말하는 kubectl Proxy는 != kube Proxy다.

Kube Proxy는 pod/service간 connectivity를 위한 인스턴스 였다면,

kubectl proxy는 kube apiserver에 접근하기 위해 kubectl utility로부터 생성된 HTTP proxy 서비스다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

K8s에서 client는 인증서를 사용하기 위해 curl 명령어를 이용하여 쿼리를 한다.

그런데, 명령어가 너무 길어지다보면 실수를 할 수도 있고 매일 이렇게 다 쳐주는 건 귀찮은 일이다.

그래서 kubeConfig File 개념이 나온다.

여기에 작성을 해 두고, 조회나 curl시 kubeConfig 를 이용하여 인증서를 조회할 수 있다.

그리고 kubeConfig 포맷은 크게 3가지 섹션으로 나뉘는데, 아래에서 알아보자.

크게 Clusters, Contexts, Users로 나뉜다.

Cluster는 말 그대로 시료 환경에 대한 것이고, clients 들은 k8s 환경에 접속하는 user들인데

각각 권한이 다르다.

Context는 어떤 Users가 어떤 Clusters에 접근하는지를 묶어주는 부분이다.

실제 KubeConfig file은 $HOME/.kube/config 디렉토리에 있으며,

clusters, contexts, users 섹션으로 나뉜다.

contexts의 cluster에 clusters name을 입력해주고, contexts의 user 부분에 users의 name을 입력해준다.

kubeConfig 파일은 위와 같이 조회할 수 있으며, current-context 수정은 오른쪽과 같이 가능하다.

# kubectl config view

# kubectl config use-context [변경할 내용]

그럼 다른 내용들을 수정/삭제하고 싶다면?

#kubectl config -h 를 통해 알아보면 된다.

Cluster내엔 다양한 namespace도 있을 텐데, kubeconfig에도 해당 namespace를 명시해줄 수 있다.

그리고 certificate-authority도 crt파일의 전체 path를 입력해줘야 하지만, 아예 

'certificate-authority-data'를 여기 파일에 직접 입력하는 방법도 있다. (물론 base64로)

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

144. Certificates API
certificate를 관리하는 방법과 certificate API가 무엇인지 다룸.

나는 이미 admin으로서 인증서가 있는 상태인데, 
우리 부서에 새로운 직원이 오면, 클러스터에 어떻게 접근을 할까?

1. 그 사람을 위한 인증서 & key pair
 -  creates her own private key using CSR(Certificate Signing Req) to admin
 -  admin takes CSR and send it to his CA server
 -  hers certificate signed by CA server using CA servers private key/root certificate
 -  now she has her own valid pair of certificate and key
    (use to access to cluster)
 

* certificate는 validated pariod가 있고,   이게 종료되면 다시 동일한 CSR 절차를 통해 CA로부터 인증서를 승인받는다.
  - 그래서 계속 certificate file을 순환시키고 CA와 통신하는데  CA Server가 뭐고, k8s의 어디에 셋업이 될까?
  - 여러 인증서를 발급하다보니 안전한 환경에 있어야 한다.
  - 인증서들은 master node에 있고, 이건 곧 CA Server다.
  - 그런데 관리하는 인증서가 많아진다면? 매번 많은 작업이 요구된다.
  - 그래서 K8s는 자체적인 Certificate API를 제공한다.

 * Certificate API
 CSR을 k8s로 direct하게 보낼 수 있다.
 admin이 master node에 로긴하는 대신 CSR을 받으면, CSR이라는 K8s API object를 생성한다. 
object가 생성되면, 모든 CSR은 cluster의 admin에 보이게 된다.
 - 그럼 CSR은 k8s cmd를 통해 Review되고, Approved 된다. 
 - 그리고 인증서는 유저와 공유된다.

 - 다시 절차를 정리해보자
  1) A user creates a key
    # openssl genrsa -out jane.key 2048
  2) generates CSR using the key with her name in it.
  3) sends CSR to admin
    # openssl req -new -key jane.key -subj "/CN=jane" -out jane.csr

  4) admin create a CSR object
     jane.csr -> object
  5) CSR object의 definition file엔 key를 일일이 입력할 필요 없고, 
     base64 명령어를 통해 jane.csr의 key를 jane-csr.yaml의 spec>request:에 복붙 하면 된다.
    # cat jane.csr | base64 

  6) CSR object를 조회해본다
    # kubectl get csr
  7) new Request / approved Req를 확인해본다
    # kubectl certificate approve jane

  8) certificate는 YAML file으로도 확인할 수 있다. (base64)
    # kubectl get csr jane -o yaml

 그럼 생성은 다 됐으니, 어떻게 동작할까?
kube-api server, scheduler, controller manager이 certificate와 모두 관련있다.
그리고, 관련된 동작은 controller manager에 의해 캐리된다.
controller mgr에 csr-appriving, csr-signing 이라는 task가 있는데, 다음 강의에서 더 자세히 알아보자.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의
  

141. View Certificate Details
인증서를 조회하는 방법

인증서에 문제가 있을 때(health check) 뭘 확인해야할까?
1. 어떻게 cluster가 셋업 됐는지 확인하기
  - Hard way: 스스로 command를 통해 config 및 certification 작성해서 띄움
  - tool: kubeadm등을 통해 클러스터 자동 생성
* 올바른 정보를 확인하기 위해 어디를 봐야하는지 아는 것이 중요함.

 1) kube-apiserver definition file 확인(/etc/kubernetes/manifests 폴더) 및 정리
  - run 'openssl x509 command -in /etc/kubernetes/pki/apiserver.crt -text -noout
   . Subject 및 alternative name 확인
   . expiry date 확인 ('Validity'> Not After)
   . Issuer: CN-kubernetes 확인 

 2) pod log 확인
  # kubectl logs etcd-master

 3) docker log 확인 (pod가 down됐을 경우)
  # docker ps -a 

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

이전 강의에서 말한 TLS 정보들이 K8s에서 어떻게 사용되는지 알아보자.

크게 두 가지로 나뉜다.

1. Server Certificates for Servers

2. Client Certificates for Clients

1. Server Certificates for Servers

K8s 내 다른 컴포넌트끼리 통신하는 방법.

Api server는 https service를 expose하니까, 클라이언트들과 모든 통신을 암호화하기위해 인증서를 필요로한다.

그래서, Kube-API서버를 위한 apiserver.crt, apiserver.key를 만든다.

etcd, kubelet도 마찬가지다. 각자 정보를 저장하고, worker노드를 관리하기에 certificate와 key가 각각 필요하다.

2. Client Certificates for Clients

Clients는 service/k8s 에 access하는 사람/것(ex. administrator, kube-scheduler)

 - 사용자는 서버를 인증하기 위해 인증서와 keeper를 필요로 한다. 

 - scheduler는 kube-api server입장에서는 client로서, cleint certificate를 이용하여 그것의 id를 validate 해야한다.

  그래서 인증서와 key가 필요하다.

- kube controller mgr, kube-proxy도 동일하다.

- 그리고, kube-api 서버도 etcd 및 kubelet server와 통신할 땐 client가 된다. 그래서 새로운 인증서/키를 생성하거나

혹은 기존 것을 동일하게 사용한다.

점점 복잡해지니 그룹핑을 해보자.

결국 api, kubelet service는 client certificate도 가지고 있고, server certificate도 가지고 있다.

그럼 인증서는 어떻게 만들어질까?

이전 강의에서 본 것처럼, 인증서를 등록하기 위해서는 certificate authority(CA) 가 필요하다.

그리고, CA는 전체 인증서와 키의 짝을 들고 있으므로, ca.crt / ca.key를 생성하여 클러스터내 사용되는 모든 인증서를 합친다.

인증서를 생성하기 위해서는, 위와 같은 3개의 툴이 있다.

그리고 이 강의에서는 openssl을 다뤄본다.

key certificates를 만들기 위한 방법은 아래와 같다.

1) Generate Keys: private key를 생성한다 

#openssl genrsa -ou tca.key 2048

2) Certificate Signing Request

# openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr 

디테일한 인증서 정보들이 포함되어 있고, component의 이름을 specify한다. (ex. CN)

예를 들어, CA를 위한 인증서를 만드니까, 그 것의 이름은 KUBERNETES-CA가 된다.

3) Sign Certificates

# openssl x509 -req -in ca.csr -signkey ca.key -out

인증서를 등록한다. 이제 CA는 그것의 Private와 root certificate를 가지고 있다.

이제 client certificate를 만들어보자.

admin 유저를 위한 인증서부터 시작하는데, 위 server 절차와 동일한 절차를 따른다.

1) Generate Keys: private key를 생성한다 

2) Certificate Signing Request

# openssl req -new -key admin.key -subj "/CN=kube-admin/OU=system:masters" -out ca.csr

3) Sign Certificates

# openssl x509 -req -in ca.csr -signkey ca.key -out

# openssl x509 -req -in admin.csr -CA ca.crt -CAKey ca.k 

// ca.crt가 추가된다: ca key pair와 인증서를 등록하기 때문. 이건 클러스터 내 유효한 인증서를 만든다.

key와 인증서를 생성하는 전체 절차는 usr account를 생성하는 절차와 비슷하다.

인증서는 validated user ID이고, key는 password 같기 때문인데, TLS는 훨씬 안전하다. 

그런데, 다른 user들과 해당 user를 어떻게 구분할까?

user 계정은 다른 basic user가 아니라, admin user의 id를 필요로 한다.

그렇다면, 이건 그룹 생성을 통해 해결해줄 수 있는데, 이 또한 인증서에 언급이 되어야 하므로

O=system:masters 옵션을 통해 CSR을 보내준다.

그럼, 이 인증서들과 무엇을 할까?

admin 인증서로는 cluster를 관리한다. curl 명령어로 username/password 대신 인증서를 사용할 수 있다.

다른 방법은, kube-config에 작성해놓는 것이다. 대부분의 client들이 이 방식을 사용한다.

+ cleint들은 server로부터 전달된 인증서를 validate하기 위해 CA public certificate copy가 필요하다.

(web app의 경우 user brower내에 자동으로 설치되어 있는)

k8s는 다양한 컴포넌트들이 있으므로, 서로를 검증하기 위해 root certificate 복사본을 각각 가지고 있다.

server side certificate의 예로 etcd 서버를 봐보자. 동일한 절차를 따르는데,

1) 다른 멤버들(Peers)과 통신하기 위해 추가적인 peer's certificates가 필요하다.

2) 인증서가 만들어지면, etcd 서버가 시작될 때 그것들을 정의한다.

  - key, cert file option 및 여러 옵션이 있고,

클라이언트가 connect하는 서버가 유효한지 체크하기 위한 root certification이 있다.

kube-api server를 보자.

kube-api server의 경우, 매우 많은 연동포인트들과 요청을 받기 때문에 kube-api server외에도 k8s 등 다양한 이름을 가지고 있다. (외부에서 봤을 땐, kube-api server를 모르므로 k8s라는 이름을 갖고있는 것이다)

그리고 이런 이름들은 발급된 인증서에 반드시 명시가 되어 있어야 하는데, 그걸 openssl.cnf 파일의 [alt_name]에 명시한다.

그리고, api server가 클라이언트로서 etcd, kubelet과 통신할 때

이런 인증서들은 api server의 service configuration 파일 내에 정의되어야 한다.

1) --client-ca-file: its client를 증명하기 위해 필요 (모든 컴포넌트들이 필요함)

2) --tls-cert/private key: api server 인증서

3) --etcd / --kubelet 정의

kubelet server를 보자. 

여긴 이름을 어떻게 정의할까? kubelet이 아니라 각 node별로 정의한다.

kubelet의 client 또한 api server와 통신하기 위해 정의를 해야하는데,

api server는 어떤 노드가 인증되어 있는지, 적합한 퍼미션을 주는지 알아야 하기 때문에

이름 포맷이 제대로 정의되어야 한다.

node는 이전 apiserver, etcd들 처럼 시스템 컴포넌트이기 때문에 format은 system부터 시작한다.

그럼 api 서버는 어떻게 맞는 퍼미션을 줄까? 그룹네임을 이용한다. 

node 또한 system node라는 그룹 네임을 추가한다. 이건 뒤에서 더 알아본다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의