쿠버네티스7-(6): Security Certified Kubernetes Administrator (CKA) with Practice Tests

 

---

167. Image Security

Image

예시 여기 이미지 nginx 는 어디서 왔을까?

.

docker 레지스트리 library 에서 가져온다.

Private Repository

private 레포지토리에서 가져올 수 있다.

먼저 private-registry.io 에 로그인 해야한다. 

image 에 전체 경로를 써야한다.

쿠버네티스가 어떻게 private 레포지토리에 인증할 수 있을까? 

워커노드의 도커 런타임에 어떻게 인증을 전달할 수 있을까 ?

-> secret 을 이용한다.

파드 정의에 secret이 들어간다.

---

168. Practice Test - Image Security 

1. What secret type must we choose for docker registry?

docker-registry 를 사용한다. 

 

 

2. We have an application running on our cluster. Let us explore it first. What image is the application using?

nginx 알파인

 

3.  We decided to use a modified version of the application from an internal private registry. Update the image of the deployment to use a new image from myprivateregistry.com:5000

The registry is located at myprivateregistry.com:5000. Don't worry about the credentials for now. We will configure them in the upcoming steps.

image 앞에 경로를 추가

4. Are the new PODs created with the new images successfully running?

작동 안된다 credential 문제인듯 

 

5.

Create a secret object with the credentials required to access the registry.

Name: private-reg-cred
Username: dock_user
Password: dock_password
Server: myprivateregistry.com:5000
Email: dock_user@myprivateregistry.com

 

 

 

6. Configure the deployment to use credentials from the new secret to pull images from the private registry

 

deployment 에 secret 을 쓸 수 있게 하자 .

 

Pull an Image from a Private Registry | Kubernetes

Pull an Image from a Private Registry

 

image 밑에 imagePullsecrets 로 넣자 .

 

7. Check the status of PODs. Wait for them to be running. You have now successfully configured a Deployment to pull images from the private registry.

잘돌아간다. 

 

---

170. Pre-requisite - Security in Docker

컨테니어와 호스트는 같은 커널을 공유한다. 

컨테이너의 네임스페이스는 밖으로 못나가지만 호스트 단의 네임스페이스는 컨테이너도 다 볼 수 있다. 

 

컨테이너 안에서 ps 명령어로 확인하면 하나의 프로세스만 뜨지만. 

 

호스트 단에 ps 명령어로 확인하면 다 나온다.

여기서는 root 의 pid 가 다르게 나올뿐 (컨테이너에서는 pid 1 이었다.)

마찬가지로 호스트 단의 root  유저와 컨테이너의 root 유저는 다르다 .

root 유저의 권한 어마무시해

권한을 주고 싶다면 --cap-add 명령을 하면 된다 .

또는 cap-drop 으로 권한을 제거할 수 있다. 

privileged 로 모두 가능하게 할 수 있다. 

 

---

171. Security contexts

도커에 유저를 추가하거나 커널 기능을 주거나.

쿠버네티스도 마찬가지

 

파드레벨

컨테이너 레벨

runAsUser 또는 capabity  등 이용가능

---

172. Practice Test - Security Contexts

1. What is the user used to execute the sleep process within the ubuntu-sleeper pod?

In the current(default) namespace.

파드에 접속한 후 whoami

 

 

2.

Edit the pod ubuntu-sleeper to run the sleep process with user ID 1010.

Note: Only make the necessary changes. Do not modify the name or image of the pod.

 

 

3. A Pod definition file named multi-pod.yaml is given. With what user are the processes in the web container started?

The pod is created with multiple containers and security contexts defined at the Pod and Container level.

오류 인가 안뜬다??

 

1002

 

4. With what user are the processes in the sidecar container started?

The pod is created with multiple containers and security contexts defined at the Pod and Container level.

명시 안되었으니 파드 단위 1001 

 

5.

Update pod ubuntu-sleeper to run as Root user and with the SYS_TIME capability.

Note: Only make the necessary changes. Do not modify the name of the pod.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
  namespace: default
spec:
  containers:
  - command:
    - sleep
    - "4800"
    image: ubuntu
    name: ubuntu-sleeper
    securityContext:
      capabilities:
        add: ["SYS_TIME"]

securityContext 를 추가한다. 

 

 

6.

Now update the pod to also make use of the NET_ADMIN capability.

Note: Only make the necessary changes. Do not modify the name of the pod.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
  namespace: default
spec:
  containers:
  - command:
    - sleep
    - "4800"
    image: ubuntu
    name: ubuntu-sleeper
    securityContext:
      capabilities:
        add: ["SYS_TIME", "NET_ADMIN"]

net_admin 추가

 

파드 실행 중이니까 바로 수정안된다. 

파드 제거하고 수정된 경로에서 kubectl apply -f [파일명]

 

---

174. Network Policy

Traffic

웹서버, 백엔드 서버, db 서버 이렇게 있다.

Ingress & Egress

Ingress - 들어오는 거

Egress - 나가는 거

Network Security

노드와 파드들은 각자 ip 를 가지고 있다. 

파드들은 서로 통신 가능해야한다.

쿠버네티스는 기본적으로 파드들끼리 allow 정책을 한다. 

쿠버네티스를 예시로 들어보자. 모두 파드로 치환됨.

파드니까 모두 서로 통신 가능하다. 

네트워크 정책을 적용해서 트래픽을 통제하자

레이블을 지정한 후 적용한다.

Network Policy - Rules 

ingress 정책 

특정 포트, 파드로 통신마 허용함

Network Policy - yaml 구성

파드 셀렉터 먼저 오고 정책 타입이 들어간다. 

인그레스 관련해서 모두 영향 받음

당연히 create 명령

네트워크 정책에 영향 받는 것과 아닌 것 확인

---

175. Developing Network Policy

 

예로 들어보자

web 으로부터 db 접근을 막아야한다. 

db와 api 먼저 확인하자

db 입장에서 api 로부터 들어오는 ingress 만 잘관리하면 된다.

요청 받은 후 응답을 자동으로 해야하기 때문에 egress는 필요없다. 

yaml 파일 예시

네임스페이스가 필요한 경우 name 밑에 기입하자

 

특정 ns가 필요하면 matchLabels 밑에 명시

이 상황에서 podSelector 가 없다면 ?

Staging에서 들어오는 모든 트래픽이 허용된다. 

다시 api pod 로 변경

외부 백업 서버와 연결하고 싶다면 ?

ipBlock 을 추가한다. 

from 아래에선 독립적으로 조건이 적용된다.

Egress 추가하기 

---

176. Practice Test - Network Policy

1. How many network policies do you see in the environment?

 

We have deployed few web applications, services and network policies. Inspect the environment.

1개

 

2. What is the name of the Network Policy?

payroll-policy

 

3. Which pod is the Network Policy applied on?

payroll

 

 

4. What type of traffic is this Network Policy configured to handle?

 

ingress 만 

 

5.  What is the impact of the rule configured on this Network Policy?

internal 

 

6. What is the impact of the rule configured on this Network Policy?

internal pod can access port 8080 on payroll pod

 

7. Access the UI of these applications using the link given above the terminal.

 

8. Perform a connectivity test using the User Interface in these Applications to access the payroll-service at port 8080.

9. Perform a connectivity test using the User Interface of the Internal Application to access the external-service at port 8080.

 

10.

Create a network policy to allow traffic from the Internal application only to the payroll-service and db-service.

Use the spec given below. You might want to enable ingress traffic to the pod to test your rules in the UI.

Policy Name: internal-policy
Policy Type: Egress
Egress Allow: payroll
Payroll Port: 8080
Egress Allow: mysql
MySQL Port: 3306

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: internal-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      name: internal
  policyTypes:
  - Egress
  - Ingress
  ingress:
    - {}
  egress:
  - to:
    - podSelector:
        matchLabels:
          name: mysql
    ports:
    - protocol: TCP
      port: 3306

  - to:
    - podSelector:
        matchLabels:
          name: payroll
    ports:
    - protocol: TCP
      port: 8080

  - ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP

 

---

휴 드디어 그 많은 분량의  section7 security 가 끝났다.

cka 너무 멀고 먼 길이여

화이팅