새소식

Recent Study/udemy - CKA with Practice Tests

KodeKloud - Test Record (section 7)

  • -

1. 아래 명령어를 통해 구성 요소의 정보를 알아낼 수 있음.

> cat /etc/kubernetes/manifests/kube-apiserver.yaml

 

2. What is the Common Name (CN) configured on the ETCD Server certificate?

> openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -text

 

3.How long, from the issued date, is the Kube-API Server Certificate valid for?

File: /etc/kubernetes/pki/apiserver.crt

> openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text

 

4. How long, from the issued date, is the Root CA Certificate valid for?

File: /etc/kubernetes/pki/ca.crt

> openssl x509 -in /etc/kubernetes/pki/ca.crt -text

 

5. Kubectl suddenly stops responding to your commands. Check it out! Someone recently modified the /etc/kubernetes/manifests/etcd.yaml file

 

You are asked to investigate and fix the issue. Once you fix the issue wait for sometime for kubectl to respond. Check the logs of the ETCD container. (kubectl 명령이 실행되지 않기에, kube-apiserver 상태를 보아야함.)

> ls /etc/kubernetes/pki/etcd (확인해보니 server.crt 로 명명되어있음. 내부 파일을 확인해보니 certificate-server.crt)

> vi /etc/kubernetes/manifests/etcd.yaml (해당 이름을 바꿔준 후 문제 수정 완료)

 

6. The kube-api server stopped again! Check it out. Inspect the kube-api server logs and identify the root cause and fix the issue.

 

Run crictl ps -a command to identify the kube-api server container. Run crictl logs container-id command to view the logs.

> crictl ps -a | grep kube-apiserver (어떤 부분에서 잘못되었는지 확인 -> etcd는 개인의 ca 파일이 존재해야 하는데, Path 경로가 잘못되어 etcd에서 쿠버네티스의 ca 파일로 인지하여 잘못된 인증서를 가지고 있는게 확인됨)

> vi /etc/kubernetes/manifests/kube-apiserver.yaml (해당 부분 수정 +/etcd)

 

7. Create a CertificateSigningRequest object with the name akshay with the contents of the akshay.csr file

 

As of kubernetes 1.19, the API to use for CSR is certificates.k8s.io/v1. Please note that an additional field called signerName should also be added when creating CSR. For client authentication to the API server we will use the built-in signer kubernetes.io/kube-apiserver-client.

 

> cat > akshay.yaml

> cat akshay.csr | base64 -w 0

> akshay.yaml 파일에 아래 복사 붙여넣고
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: akshay
spec:
  groups:
  - system:authenticated
  request: <Paste the base64 encoded value of the CSR file>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

> kubectl apply -f akshay.yaml

 

 

8. (1) What is the Condition of the newly created Certificate Signing Request object? (2) Approve the CSR Request, (3)어떤 csr에 접근을 원하는지, (4) That doesn't look very right. Reject that request.

> kubectl get csr

> kubectl certificate approve akshay

> kubectl get csr agent-smith -o yaml

> kubectl certificate deny agent-smith

> kubectl delete csr agent-smith

 

9. Where is the default kubeconfig file located in the current environment? Find the current home directory by looking at the HOME environment variable. (context의 user configured는 해당 kube config 파일 내에서 context -> user를 봐야한다.)

> ls .kube/config

 

10. I would like to use the dev-user to access test-cluster-1. Set the current context to the right one so I can do that.

> k config use-context research --kubeconfig /root/my-kube-config

 

11. We don't want to have to specify the kubeconfig file option on each command. Set the my-kube-config file as the default kubeconfig by overwriting the content of ~/.kube/config with the content of the my-kube-config file.

> mv /root/my-kube-config /root/.kube/config

 

12. With the current-context set to research, we are trying to access the cluster. However something seems to be wrong. Identify and fix the issue. Try running the kubectl get pods command and look for the error. All users certificates are stored at /etc/kubernetes/pki/users.

> ls /etc/kubernetes/pki/users/dev-user/

> cat /root/.kube/config (해당 users 섹션의 파일명과 바깥 파일명이 다름)

> vi /root/.kube/config (수정)

 

RBAC

13. Inspect the environment and identify the authorization modes configured on the cluster. Check the kube-apiserver settings.

> cat /etc/kubernetes/manifests/kube-apiserver.yaml

 

14. How many roles exist in the default namespace?

> kubectl get roles

> kubectl get roles -A

 

15. What are the resources the kube-proxy role in the kube-system namespace is given access to?

> kubectl describe role kube-proxy -n kube-system

 

16. Which account is the kube-proxy role assigned to?

> kubectl describe rolebinding kube-proxy -n kube-system

 

17. A user dev-user is created. User's details have been added to the kubeconfig file. Inspect the permissions granted to the user. Check if the user can list pods in the default namespace. Use the --as dev-user option with kubectl to run commands as the dev-user.

> kubectl config view

> kubectl get --as dev-user

 

18. Create the necessary roles and role bindings required for the dev-user to create, list and delete pods in the default namespace. Use the given spec:

> kubectl create role developer --verb=list,create,delete --resource=pods

> kubectl create rolebinding dev-user-binding --role=developer --user=dev-user

19. A set of new roles and role-bindings are created in the blue namespace for the dev-user. However, the dev-user is unable to get details of the dark-blue-app pod in the blue namespace. Investigate and fix the issue. We have created the required roles and rolebindings, but something seems to be wrong.

> kubectl edit role developer -n blue (수정)

 

20. Add a new rule in the existing role developer to grant the dev-user permissions to create deployments in the blue namespace. Remember to add api group "apps".

> kubectl --as dev-user create deployment nginx --image=nginx -n blue (테스트)

> kubectl edit role developer -n blue (apigroups 추가)

 

 

Cluster Roles

21. How many ClusterRoles do you see defined in the cluster?

> k get clusterroles --no-headers | wc -l

 

22. A new user michelle joined the team. She will be focusing on the nodes in the cluster. Create the required ClusterRoles and ClusterRoleBindings so she gets access to the nodes.

> kubectl create clusterrole michelle-role --verb=get,list,watch --resource=nodes

> kubectl create clusterrolebinding michelle-role-binding --clusterrole=michelle-role --user=michelle

 

23. michelle's responsibilities are growing and now she will be responsible for storage as well. Create the required ClusterRoles and ClusterRoleBindings to allow her access to Storage. Get the API groups and resource names from command kubectl api-resources. Use the given spec:

 

> k create clusterrole storage-admin --resource=persistentvolumes,storageclasses --verb=list,create,get,watch

> k create clusterrolebinding michelle-stroage-admin --user=michelle --clusterrole=storage-admin

 

 

Service Accounts

24. How many Service Accounts exist in the default namespace?

> k get serviceaccounts

 

25. What is the secret token used by the default service account?

> k describe serviceaccounts default

 

26. We just deployed the Dashboard application. Inspect the deployment. What is the image used by the deployment?

> k get deploy

> k describe deploy web-dashboard

 

27. The application needs a ServiceAccount with the Right permissions to be created to authenticate to Kubernetes. The default ServiceAccount has limited access. Create a new ServiceAccount named dashboard-sa.

> k create sa dashboard-sa

 

Image Security

28. 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

> kubectl edit deploy web 

 

29. 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

 

> kubectl create secret docker-registry private-reg-cred --docker-server=myprivateregistry.com:5000 --docker-username=dock_user --docker-password=dock_password --docker-email=dock_user@myprivateregistry.com

 

Security Contexts

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

In the current(default) namespace.

 > kubectl exec ubuntu-sleeper -- whoami

  

31. 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.

> k get pod ubuntu-sleeper -o yaml > ubuntu-sleeper.yaml

> vi ubuntu-sleeper.yaml

> kubectl delete pod ubuntu-sleeper --force

> k apply -f ubuntu-sleeper.yaml

 

Network Policies

32. How many network policies do you see in the environment? We have deployed few web applications, services and network policies. Inspect the environment.

> k get netpol

33. 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.

Also, ensure that you allow egress traffic to DNS ports TCP and UDP (port 53) to enable DNS resolution from the internal pod.

 

> vi internal-policy.yaml

 

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

 

> kubectl create -f internal-policy.yaml

'Recent Study > udemy - CKA with Practice Tests' 카테고리의 다른 글

KodeKloud - Test Record (section 8)  (1) 2024.07.20
Section 8 : Storage  (0) 2024.07.20
Section 7 : Security  (0) 2024.07.12
KodeKloud - Test Record (section 6)  (0) 2024.07.02
Section 6 : Cluster Maintenance  (0) 2024.07.02
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.