udemy)CKA 강의 듣고 따라하기_7장_security :: mightytedkim

udemy)CKA 강의 듣고 따라하기_7장_security

+ 후기 
수강기간 : 0908-

(수강 전)
보안 부분은 2시간 20분이나 됨ㅜ 잘 모르는 분야라 무섭기도하고
결국 넘어야할 중요한 부분이라 정신 바짝차리고, 이번주 주말에 완강하는 걸 목표로 해야겠다.
다행히 아주 기초 단계로 설명해준다고 한다.

(수강 후)

---

Section 7: Security 0 / 33 | 2hr 21min

132. Security - Section Introduction 2min

> 개요 설명

 

어떻게 사용자가 접근하고, 관리되는지

기본 설정을 예시를 통해 보고, tls certicate 등을 볼 예정

아주 기초부터 볼거기 때문에 많은 시간이 걸리게 구성이됨

 

 

133. Download Presentation Deck 1min

> 자료 제공

 

 

134. Kubernetes Security Primitives 3min

> high level에서 security를 보기

1. kube-apiserver(가장 중심): kubectl 또는 api로 접근하는 방식을 제어하는 것 - who?  files, certificates, LDAP, service account - what?   RBAC Authorization, ABA, Node, WebHook + network policies: 기본적으로 pod끼리 접근이 가능

135. Authentication 6min

> kube-apiserver 를 이용한 인증방식을 설명하지만 추천하지는 않음

service account는 어플리케이션(로봇) user는 kube-apiserver가 관리 어떻게 kube-apiserver가  인증을 관리할까? - static password file, static token file, certificates, identity service(kerberos) static (password, token file) -> "NOT RECOMMENDED" - user-details.csv: pwd1/user1,user001 - kube-apiserver.service -> --basic-auth-file=user-details.csb   -> restart kube-apiserver   if kubeadm tool -> restart -> 알아서 적용

136. Article on Setting up Basic Authentication 1min

> 문서

kube-apiserver 인증 방식 문서

137. TLS Introduction 1min
> TLS 교육 과정 관련 소개

TLS 어려워서, TLS 기본기를 먼저 다룰 예정 - TLS가 무엇인지 파악 - k8s 에서 어떻게 사용하는지 - 생성/설정/보기 - 문제 파악

138. TLS Basics 20min
> tls 기초

certificate: 보증하는 것 암호화하지 않고 데이터 보내면, 중간에서 훔칠 수 있음 이를 방지하고자 encrypt key를 이용함 하지만 서버도 decrypt해야하기 때문에 key가 필요함 1. symmetric encryption: 같은 네트워크로 encrypt, decrpypt key 보내면 위험함 2. assymmetric encryption: private key/ public lock(key) public lock으로 암호화하면, pricate key로만 해제할 수 있음 * 개인 컴퓨터: key pair 생성하기: ssh-keygen -> id_rsa, id_rsa.pub   - user1 * 접근할 서버: public lock을 이용해 server를 잠금: cat ~/.ssh/authorized_keys   - server1, server2 * 개인 컴퓨터   - ssh -i id_ras user1@server1 으로 접근   - ssh -i id_ras user1@server2 으로 접근 --------------- symmetric encryption로 다시 돌아가면, 같은 네트워크로 decrypt key와 데이터가 전송되서 의미가 없어진다는 문제가 있었음 하지만 assymmetric encryption은 해커가 private key를 가지고 있기 때문에 도중에 데이터를 뺏겨도 문제가 없음 > openssl genrsa -out my-bank.key 1024 > openssl rsa -in my-bank.key -pubout > mybank.pem ------ 하지만 이것도 해커가 피싱 웹사이트를 만들면 해킹할 수 있음 이를 위해 certificate을 공인된 단체에서 인증을 받는 것이 중요함 누가 만들고, 발행했는지가 중요함 (certificate authority-CA) self-signed certifcate인지 보는게 중요함 ------ pricate ca 서버를 만들어서, 내부에서 사용할 수 있음 1. 데이터를 암호화하는 것이 중요함 2. 방법으로 symmetric, assymetric이 있음 3. certificate authroity가 인증서를 증명해줌 4. 사설로 인증서 확인하는 서버를 만들기도 함 일반적인 naming rule - certificate(public key): *.crt, *.pem - private key: *.key, *-.key.pem 으.. 어렵다. 대충 알고 있는 부분이라 다시 공부해야겠다.

139. TLS in Kubernetes 8min
> k8s에서 사용하는 인증서

tls의 개념은 배웠고, k8s에서 어찌 사용되는가 1. k8s는 master와 worker의 묶음 2. api통신할 때 암호화되야함 3. certificate 활용해야함(server, client) --- (3개) server certificates for servers - kue-api server용   1. apiserver.crt/ apiserver.key - etcd server   2. etcdserver.crt / etcdserver.key - kubelet server   3. kubelet.crt / kubelet.key (7개) client certificates for clients - admin user (admin user가 접근하는 kubectl rest api)  1. admin.crt/ admin.key - kube scheduler  2. scheduler.crt/ scheduler.key - kube-controller manager  3. controller-manager.crt/controller-manager.key -  kube-proxy  4. kube-proxy.crt/ kube-proxy.key -  kube-api server  5. apiserver-kubelet-client.crt/ apiserver-kubelet-client.key  6. apiserver-etcd-client.crt/ apiserver-etcd-client.key      - etcd와 통신하는 kube-api server 밖에 없음 - kubelet server  7 kubelet-client.crt/ kubelet-client.key

140. TLS in Kubernetes - Certificate Creation 11min
> 급 어려워짐..

openssl을 이용해서 certificate을 만들 예정 [CA] 1. generate keys - 비밀번호 개념  $ openssl genrsa -out ca.key 2048  # ca.key   2. certificate signing request  $ openssle req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr  # ca.csr 3. sign certificate  $ openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt  # ca.crt [ADMIN user] 1. generate keys - 비밀번호 개념  $ openssl genrsa -out admin.key 2048  # admin.key   2. certificate signing request  $ openssle req -new -key ca.key -subj "/CN=kube-admin" -out admin.csr  # admin.csr + 그룹을 추가하고 싶으먄  $ openssle req -new -key ca.key -subj "/CN=kube-admin/O=system:masters"-out admin.csr 3. sign certificate  $ openssl x509 -req -in ca.csr -signkey ca.key -out admin.crt  # admin.crt [kube-scheduler] [kube-proxy] 다 만들었다고 가정하면 curl로 key cert cacert를 전달할 수도 있고 kube-config.yaml로 전달할 수 있음(가장 많이 사용) 갑자기 너무 어려워짐... 형 말하는 속도 갑자기 미친듯이 빨라짐. x2 배속한줄.. kube-api server가 곧 kubernetes라고 봐도 무방함 kubernetes/kubernetes.default/kubernetes.default.svc/kubernetes.default.svc.cluster.local + 이래서 argocd에서 in-cluster하면 해당 도메인이 나오나보다 domain을 추가하려면? openssl.cnf에 [alt_name]을 다 넣어줘야함 api-server.crt 를 만들고 설정해줌(자동으로 해줌) (모든 작업은 kube-api server를 통하게됨) 각 node에는 kubelet 관련 인증서가 필요함 kubelet-config.yaml 강의 듣고 보니까 인증성 엄청 많음

141. View Certificate Details 5min
> 어떻게 인증서를 보는지

인증성의 healthcheckrk 중요함 수작업으로 설치하거나 kubeadm으로 설치하는 방법이 있음 어려운 방법 -> cat /etc/systemd/system/kube-apiserver.service 쉬운 방법 -> cat /etc/kubernetes/manifests/kube-apiserver.yaml cat /etc/kubernetes/manifests/kube-apiserver.yaml 안에있는 설정값들을 하나씩 보면됨 예를 들어 apiserver.crt의 경우 그냥 출력하면 안되는데 decode하면 값이 나옴 Issuer 부분이 kube-apiserver가 있는 것을 확인할 수 있음 altname도 로그는 2가지 방법이 있음 1. journalctl -u etcd.service -l (수작업으로 실행한다면 os에서 볼 수 있음) 2. k logs etcd-master (kubeadm은 pod를 보면 됨) kubectl에  접근이 안되면 docker ps로 볼 수도 있음

142. Resource: Download Kubernetes Certificate Health Check Spreadsheet 1min

> 링크를 하나 줌

https://github.com/ddometita/mmumshad-kubernetes-the-hard-way/blob/master/tools/kubernetes-certs-checker.xlsx 보기만해도 어질어질함 Checks to perform: 1. Make sure the correct CN and ALT names, Organization are present.    Specifically for the kube-api server and the nodes(kubelets). 2. Ensure the certificates are not expired. 3. Ensure the certificates are issued by the right CA. 4. Ensure the correct certificate path is provided in the options on the service configuration files

143. Practice Test - View Certificates 0min
>테스트 너무 어려움

etcd-server의 경우 별도의 ca.crt를 사용한다

144. Certificates API 6min
> certificate manager + api 이해

다양한 인증서들이 있음 특정 사용자용 key pair가 필요하면, admin이 새로 인증해줘야함 이 떄 필요한게 CA 관리자는 알아야하는 개념 여기서 갑자기 또 엄청 어려워짐 - certificateSigningRequest 1. 사용자가 키를 만들고 $ openssl genrsa -out jane.key 2048 2. 관리자에게 요청을 보냄 $ openssl req -new -key jane.key -subj "/CN=jane" - out jane.csr 3. 관리자가 jane.csr 을 가지고 signingRequest object를 만듦 (kind) $ cat jane.csr | base64 | tr -d n" #request 부분에 복사함 $ k get csr $ k certificate approve jane $ k get csr  ----- 이 모든 것은  KUBE-API server의 controller manager가 진행해줌 manifest/kube-controller-manager.yaml - csr-approving - csr-signing

145. Practice Test - Certificates API 0min
> csr 예시

csr 처음 만들면 condition이 pending인데 k certificate approve *** 해줘야 Approved, Issued가 됨 거절은 k certificate deny ***

146. KubeConfig 9min
>

kubectl get pod --kubeconfig config $HOME/.kube/config 파일에 --server --client-key --client-certificate --certificate-authority 총 3가지로 구분이됨 Clusters  - development, production, cloud Contexts  - cluster와 user를 연결 Users  - 접근 권한(admin, dev, prod) default context -> current-context로 정의할 수 있음 아래는 한개씩 만 있는데 여러개를 넣을 수 있기 때문 k config view 로 요약 본을 볼 수 있음 k config user-context prod-user 로 정의하면 default 변경할 수도 있음 -- namespace도 설정할 수 있음 Context에 정의하면 됨 kubeconfig에는  certificate-authority : 경로/ca.crt 또는 certificate-authrority-data : xxx | base 64 로 직접 넣어줄수도 있음

147. Practice Test - KubeConfig 0min
> 항상 기본 cluster만 사용했는데, 신기했음

특정  context를 이용해서, user가 cluster에 접근하도록 정의하는 방식 -> use-context $ kubectl config --kubeconfig=/root/my-kube-config use-context research Switched to context "research". $ kubectl config --kubeconfig=/root/my-kube-config current-context  research

148. Persistent Key/Value Store 1min
> 앞에서 했다고 스킵함

스킵할거면 왜 넣었는지 모르겠..

149. API Groups 6min
> api group에 대해서 생각안해봤는데 재밌었음. 근데 설명이 좀 부족한듯

ㅇkube api server가 곧 k8s라고 봐도 됨(사용자 입장에서는) version check -> curl https://kube-master:6443/version pod check -> curl https://kube-master:6443/api/v1/pods /api (core) -> /v1 -> namespaces, pods, rc, events, endpoints, ndoes, pv, pvc 등등 curl http://localhost:6443 -k  /apis (named) -> /apps /extensions /storage.k8s.io 등등  -> [api group] /v1/ [resources]  -> apps/v1: /deployments, /replicatsets / statefulsets  -> networking.k8s.io/v1: networkpolicies curl http://localhost:6443/apis -k | grep "name"  그냥 접근하면 권한 문제로 fobidden나오는데 인증 방법을 명시하지 않아서 그럼. 명시하지 않고 하는 방법은 kubectl proxy를 사용하는것 curl http://localhost:8001  -k 로하면 결과가 쭉 나옴 2개는 다름, kube proxy != kubectl proxy --- 그 외 /metrics /healthz /logs  등이 있음

150. Authorization 8min
> 권한 부여 방식 방법에 대해서 설명

이제까지 앞은 Authentication 맞는지 확인만 하는거고 권한에 대해서는 지금 부터 시작 사용자나 젠킨스 등의 용도로 접근 권한을 제한하고 싶음 node , abac, rbac, webhook이 있음 1. node Kubelet이 kube api server에 접근하는것이 기본 이 때는 node authorizer를 사용하는데 전에 언급한 certificate이 필요함 2. abac external 접근 dev-user의 경우인데., Policy로 접근권한을 정의함 policy 파일 수정하면, kube-api server를 재시작해야함 3. rbac role을 만들어서 할당하기 때문에 훨씬 간단함 4. webhook open policy agent를 활용하는 방법 kube-api에 접근하는건 똑같지만 권한부여를 다른곳에 요청하는것 Kubeapiserver에 --authrozation-mode로 설정할 수 있음 기본 값을 AlwaysAllow임 여러개를 설정할 수도 있는데 --authorization-mode=Node,RBAC,Webhook이렇게 두면 node에서 통과되면 끝 node가 안되면 rbac으로 넘어가는 식으로 진행됨

151. Role Based Access Controls 4min
> role 확인하는 명령어가 있음 (CAN-I) 귀여움

여기는 아는 부분이어서 가볍게 들음 role과 rolebinding은 namespace 내에서 동작함 access를 확인하는 방법도 있음 (can-i) $ k auth can-i create deployements $ k auth can-i create deployements --as dev-user $ k auth can-i create deployements --as dev-user -n test # yes # no

152. Practice Test - RBAC 0min
> rbac 예제는 특별히 막히는 부분 없었음

이제 슬슬 지지기 시작.. secuity 부분은 3시간이 넘던데..걱정 10,11번은 맞게 수정했는데 잘 안되는듯

153. Cluster Roles and Role Bindings 5min
> cluster scop rbac 설명

role과 달리 namespace 가리지 않고 권한부여를 관리할 수 있는게 clusterrole, clusterrolebinding node 같은 유형은 cluster 구간에서 관리되기 때문에 clusterrole을 이용하게 됨 cluster scope -> nodes, pv, clusterroels, clusterrolebinding, namespaces , certificatesigningrequests 하지만 clusterrole로 namespace 지정할 수 잇긴 함 -> 나중에 다시 공부

154. Practice Test - Cluster Roles and Role Bindings 0min
>

특정 사용자가 node에만 작업할 경우의 예시 너무 좋아서 메모 $ cat michelle-role.yaml  apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: node-admin rules: - apiGroups: [""]   resources: ["nodes"]   verbs: ["get", "watch","list","create","delete"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: michelle-binding subjects: - kind: User   name: michelle   apiGroup: rbac.authorization.k8s.io roleRef:   kind: ClusterRole   name: node-admin   apiGroup: rbac.authorization.k8s.io 이거는 storage 권한 추가될때 $ cat michelle-storage.yaml  apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: storage-admin rules: - apiGroups: [""]   resources: ["persistentvolumes","storageclasses"]   verbs: ["get", "watch","list","create","delete"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: michelle-storage-admin subjects: - kind: User   name: michelle   apiGroup: rbac.authorization.k8s.io roleRef:   kind: ClusterRole   name: storage-admin   apiGroup: rbac.authorization.k8s.io

155. Service Accounts 8min
> sa 단순히 사용만했는데, token과 관련된지 알 수 있었음

sa는 보안과 관련된 user  / service account가 있는데 1. user: admin/developer 2. bot: airflow, spark, prometheus $ k create sa dashboard-sa $ k get sa sa가 만들어지면 token이 함께 만들어지는데, 이게 사용됨 (secret object임) 1. sa -> 2. token -> 3. secret에 token 저장 -> 4. sa와 secret object 연결됨 k8s의 pod들을 연결하려면, sa의 secret을 pod에 정의해도됨 $ k get sa # default가 있음 -> namespace마다 default sa가 있음 default sa와 token이 pod마다 mount됨 describe로 mounts: 쪽을 보면 default-token-xxx가 연결된걸 볼 수 있음 $ k exec -it my-k8s-dashboard ls /var/run/secrets/kubernetes.io/serviceaccount pod내에 sa 추가하려면 삭제 후 다시 만들어야함 deployment는 알아서 다시 pod 만들어주니, pod가 아닌 deployment를 수정해야함 --automountServiceAccountToken: True (default) 이기 때문임

156. Practice Test Service Accounts 1min
> sa 예시 어려운거 없었음

deployment의 spec 밑에 serviceAccountName 추가하면 token 복사안해도됨   spec:       serviceAccount: dashboard-sa

157. Image Security 5min
>

secure image repo를 이야기하는걸로봐서 private repo 말하는 듯 image 경로를 전체로 적으면됨 하지만 인증은 어떻게하지? -> 난 어떻게 했더라.. docker runtime에 전달해주면됨 여기서는 imagepullsercret했는데 나는 다른 방식 사용함 https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

158. Practice Test - Image Security 0min
> imagepullsercret을 이용하는 방법 테스트

cat <<EOF > pod.yaml apiVersion: v1 kind: Pod metadata:   name: foo   namespace: awesomeapps spec:   containers:     - name: foo       image: janedoe/awesomeapp:v1   imagePullSecrets:     - name: myregistrykey EOF

159. Security Contexts 2min
>

pod 단계에서 보안 설정할 수도 있고 container 단계에서도 할 수 있음 pod spec:   securityContext:     runAsUser: 1000 container spec:   containers:   - name: ubuntu      securityContext:       runAsUser: 1000

160. Practice Test - Security Contexts 0min
>

어느 사용자가 pod를 실행하고 있는지 체크 kubectl exec ubuntu-sleeper -- whoami securitycontext는 pod 재시작해야함 좋은 예시 apiVersion: v1 kind: Pod metadata:   name: multi-pod spec:   securityContext:     runAsUser: 1001   containers:   -  image: ubuntu      name: web      command: ["sleep", "5000"]      securityContext:       runAsUser: 1002   -  image: ubuntu      name: sidecar      command: ["sleep", "5000"]

161. Network Policy 8min
> 네트워크 기본

traffic도 신경써야함 ingress /egress 는 traffic의 방향을 지칭하는것 상대적인거라고 보면됨 node가 여러개 있고, 각각 cluster가 있다고 가정해도 pod끼리는 통신 가능하다는게 기본 전제임 이거를 어떻게 가능하게 할까? ip, podname 등을 설정해서 all Allow 규칙으로 traffic이 소통가능하게 되어 있음 pod끼리 통신 못하도록 제한하는건 network policy가 있음 pod를 보호하는 개념 kind: NetworkPolicy policyTypes에 ingress, exgress가 명시되어 있어야함 Flannel은 netowrk policy 제공하지 않음 calico, kube-router등은 지원함 (으헝.. 난 테스트로 flannel 넣었는데)

162. Developing network policies 12min
>

network policy로 pod끼리 통신 제한할 수 있다는 걸 봤음 network policy를 만들고, 특정 pod와 연결하는거임 -> matchLabels를 사용함 api pod가 db pod에 request보낼 때 -> db pod에 ingress 설정하면 됨 ingress: - from:   - podSelector:       matchLabels:         name: api-pod   - namespaceSelector:        matchLabels:          name: prod    - ipBlock:        cidr: 102.168.5.10/32   ports:   - protocal: TCP     port: 3306 and처럼 작동한다고 보면됨 egress도 비슷함

163. Practice Test - Network Policy 0min

> 맛보기 예시

생각보다 예시는 쉬웠지만 마지막 예시는 갑자기 난이도 상승함 여기는 이해보다는 이런게 있구나 정도로 맛보기로 넘어감

164. Solution - Network Policies (optional) 12min

>오랜만에 예시 문제 같이 풀어줌

마지막 문제 막혔는데 공식 문서가서 복붙해옴.. 현타옴

 

security 부분은 봐도 봐도 어려운듯 ㅜ

연휴 기간동안 network까지 들으려했는데 실패함