k8s 운영관리 보강 #1

 Course Overview

• Muli Tenancy Use case (Today)
• Kubernetes Security (Authentication & Authorization) (Today)
• Helm (Today)
• Istio (Tomorrow)

C:\Program Files (x86)\VMware\VMware Player\vmwaredll\vmnetcfg.exe

 

 

vm player 실행 후 c:\vm\node1, 2, 3 열고  memory 4GB로 설정

 

node 1: 10.32.2.137 (master) - 같은 클러스터

node 2: 10.32.2.162 (worker) - 같은 클러스터

node 3: 10.32.2.161 (master)

 

 

Multi-tenancy in k8s

 

Access Control: RBAC(role 권한 인가), Network policy, Admission Control(인증), PSP(pod secret policy)

Scheduling: Resource Quota, Limit Range, Pod Affinity

 

인증, 인가 공유 - master node 공유

1. Namespace per Tenant

Cluster, Node는 공유

 

(scope 차이라고 생각하면 됨)

Rolebinding - Role

:  하나의 namespace 안에서 사용하고 싶은 경우

 

Cluster Rolebinding - ClusterRole

: 어떤  role 하나 이상의 namespace에게 주고 싶은 경우

 

ResourceQuota > LimitRange

 

LimitRange

: pod에 limit, resource 가 없을 시에도 정해준다.

: Resource 자원(cpu, memory)에 대한 정의 default, max, min / namespace 에 정의함

 

ResourceQuota

: 기능이 더 많음

하나의 namespace 에 있지만 class를 나눠서 적용 가능

hard: / request, limits (cpu, memory) / namespace에 apply (limit range와 동일)

차이점은 default가 없음

namespace 에서 생성할 수 있는 resource object 사용 가능

 

2. Nodes per Tenant

-> node sizing이 어려움

(1, 2는 single cluster 공유: master node / access control 확인하는 것이 중요)

 

1) Node Lable - NodeSelector, Node(Anti)Affinity

 

Node (anti or)affinity

pod / node

참조하는 값은 label

 

우리는 실습할 때 pod affinity 할 예정

 

2) Node Taint - Toleration

 

o declarative

spec:

  taints:

- effect: NoSchedule

   key: example-key

o imperative

kubectl taint node node1 example-key: ..

 

o tolerations:

pod 배포는 하지만  NoSchedule 에 값을 가지고 있는 것 상관없이 tolerations를 통해서 배포가 되도록 처리됨.

 

 

3. Cluster per Tenant

우리는 tenant마다 cluster 따로 생성하자

-> Tenant를 추가하려면 새롭게 Tenant 생성

이럴때에는 create cluster 해주는 cluster API 올려줌

 

아무것도 공유하지 않고 단독적으로 실행됨

Individaul Resources - cluster

 

1) Cluster API

다양하게 multi cluster를 관리할 수 있는 관리 도구 제공

 

Access Control

1) Authentication

: 누군가가 접근하기 위해 안가를 받음

2) Authorization

: 인증을 받은 사람이 요청한 것에 대한 응답을 보내줄 수 있는 지 여부

3) Admission Control

: 요청한 생성 요청을 인증받아 권한에 따라서 어느 namespace에 pod 가 생성되는지 안되는지..

 

API Server - Authentication

User (kubuctl) / Service Accounts(Pod로 배포된 app) 가 API Server 에 접근

명령을 날리기 전에 접속할 수 있는 사람인지 '인증'

woker node 위에 떠있는 kubelet / kube-proxy가 API Server 와 계속해서 연결되어야 함 => 이때도 '인증' 필요함

 

master 가 발행한 token -> API Server 와 통신

Scheduler도 API server 와 메세지를 주고받고 통신함

 

kubectl hard way -> CKA

서비스를 하나씩 올리는 것 해야하고 trouble shooting

 

Authentication Plugins

* Client Certificates - default when using kubeadm / Most commonly used

* Authentication Tokens - Service Accounts

 

 

Users in Kubernetes

kubectl get nodes 했을 때 어느 API Server 에 접근해서 인증을 하고 결과가 나오는가?

user는 kubernetes의 object가 아니고 node1에 root 계정으로 접속해서 명령어를 실행을 했더니 -> kubectl 명령어를 실행하는 user는 누구일까?

 

> kubectl get nodes -v 6

> cat .kube/config

내용 확인해보면,

- cluster : 

    certificate-authority-data: ..

- context:

     cluster: kubernetes

     user: kebernetes-admin

 

users:

- name: kubernetes-admin

  user:

      client-certificate-data:

 

Service Accounts

API Server 통신 시스템 내부 pods 들

namespaces API Object

 

> kubernetes api-resources --namespaced=true

serviceaccounts             sa           v1                             true         ServiceAccount

 

namespace마다 serviceAccont가 하나씩 생성됨

pods 배포한다면 serviceAccount - default의 token 으로 실행됨

 

 

kubectl create role demorole --verb=get,list --resource=pods
kubectl create rolebinding demorolebinding --role=demorole --serviceaccount=default:mysvcaccount1 

 

-> 내 namespace에 role binding

 

Pod Security Policy

Single Cluster - multiple Contexts

admin.conf 파일로 복사해주면 다른 사람도 관리자처럼 master로 접속해서 사용할 수 있음

 

user 한명을 더 만들어서 새로운 user가 context 사용하는 예제 실습 진행

 

csr -> certificate singing request 나에게 인증서 만들어주세요 =>  CA 에게 요청 (우리에게 CA는 kubernetes)

 

crt 파일로 만들어짐 !

kubectl get certificatesigningrequests demouser \
  -o jsonpath='{ .status.certificate }'  | base64 --decode > demouser.crt 

root@node1:~# openssl x509 -in demouser.crt -text -noout | head -n 15
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            81:b7:c4:ae:c3:eb:33:8b:19:fd:bc:cb:bd:8f:e0:b9
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = kubernetes
        Validity
            Not Before: Feb  1 06:34:33 2021 GMT
            Not After : Feb  1 06:34:33 2022 GMT
        Subject: CN = demouser
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:

kubectl get pods --as=demouser

인증은 됐지만 아직 API Server에 get 할 수 있는 role이 없기 때문에 forbidden 발생

 

kubectl create role demorole --verb=get,list --resource=pods --namespace ns1 --dry-run=client -o yaml

(declarative한 파일을 보여달라는 의미)

--dry-run=client: 실제 생성은 안하고 object을 생성하기 위한 yaml template 생성해줘!

 

node는 namespace role이 아니라 cluster role이기 때문에

 

 

Context 구성 요소 (admin.config)

cluster - certificate /  server

users - certificate key / key-data

root@node1:~# k config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin

 

 

demo.config 파일 만들자

 

 

MultiCluster Access Control

product cluster user 생성ca 생성config 생성root/product .config 넣어주면 새로운 user 정해진 role 사용 가능