[Recap] Day 3 – Secure Ingress, and Restrict Access to Node Metadata [Certified Kubernetes Security Specialist] [CKS]

In this post, I am going to share some quick tips, including Q/A and valuable links from the Day 3 live session of our current batch of Certified Kubernetes Security Specialist [CKS].

Are you also planning to get a Certified Kubernetes Security Specialist [CKS] now, or would you like to do so anytime in the near future?

This series will help you gain a better understanding and make it easier for you to learn Docker and Kubernetes, clearing Certification [CKS] & get a better-paid job.

On our Day-1 & Day-2 of the Certified Kubernetes Security Specialist training program, we have gone through the installation of Kubernetes Dashboard & set permission on Dashboard using RBAC, introduction to the service account and Kubernetes Network Policy right from scratch. Now on Day 3 of our training program, we covered these topics:

• Create & Secure Ingress Resource

Then we went ahead with Access and Restrict access Node Metadata concepts and introduced why it is an essential aspect in Kubernetes.

• Access and Restrict access Node Metadata

We even started with the Verification of platform binaries and discussed why it is important in Kubernetes.

• Verify platform binaries

We also covered hands-on Lab 2, Lab 3, Lab 4 & Lab 5 out of our 27+ extensive labs.

↦ Know everything about the CKS Certification

So, here are some of the Q/A’s asked during the Live session from Module 2: Kubernetes Cluster Setup.

➪ Create & Secure Ingress Resource

In Kubernetes, an Ingress is an object that allows access to your Kubernetes services from outside the Kubernetes cluster. You configure access by creating a collection of rules that define which inbound connections reach which services. This lets you consolidate your routing rules into a single resource.

We can secure a Kubernetes application by producing a secret that includes a TLS (Transport Layer Security) private key and certificate. Ingress only supports one TLS port, 443, and assumes TLS termination.

Q-1. How to create ingress resources?

Ans. The following file is an Ingress resource that sends traffic to your Service via host hello-world

Create example-ingress.yaml from the following file

Create the Ingress resource by running the following command:

$ kubectl apply -f Download File

Q-2. How to secure ingress resource and how does it works?

Ans. A common use-case for cert-manager is requesting TLS signed certificates to secure your ingress resources. This can be done by simply adding annotations to your Ingress resources, and the cert-manager will facilitate creating the Certificate resource for you. A small sub-component of cert-manager, ingress-shim, is responsible for this.

➪ Access and Restrict access Node Metadata

Cloud platforms (AWS, Azure, GCE, etc.) often expose metadata services locally to instances. By default, these APIs are accessible by pods running on an instance and can contain cloud credentials for that node or provisioning data such as kubelet credentials. These credentials can be used to escalate within the cluster or to other cloud services under the same account.

When running Kubernetes on a cloud platform, limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API and avoid using provisioning data to deliver secrets.

➪ Verify platform binaries

This topic is pretty self-explanatory as administrators would need to ensure whatever that would be installed inside K8s clusters should be intact and complete. So, we compare the downloaded file sha512sum with the string provided on the GitHub page.

We use this site and search for the version we would desire to install in K8s clusters.

Q-1. How to verify platform binaries?

Here, You would need to know v1.20.2 details, so click on v1.20.2.

Then, click on CHANGELOG and find Server binaries.

Depends on the processor K8s clusters are running on, different server binaries would have different sha512sum. The next step is to download the binaries into the server and compare it to the string shown on the site.

• echo “” > compare
• wget
• sha512sum >> compare
• cat compare | uniq

Quiz Time!

With our Certified Kubernetes Security Specialist [CKS] training program, we cover real exam questions to help you prepare for the CKS certification.

Check out one of the simple questions and see if you can crack this…

Ques: If ingress is declared in a network policy, but no rules, then:

A. All ingress is allowed

B. No ingress is allowed

C. It is not parsed by the API server

The right answer will be revealed in my next week’s blog.

Here is the answer to the question shared last week.

Ques: Which of the following is not a type of security attack?

A. Active

B. Passive-aggressive

C. Passive

Correct Answer: B

Explanation:

There are two types of Security attacks are Active and Passive attacks. An active attack attempts to alter system resources or affect their operations and involve some modification of the data stream or creation of false statements whereas Passive attack attempts to learn or make use of information from the system but does not affect system resources.

Feedback

We always work on improving and being the best version of ourselves from the previous session hence constantly ask feedback from our attendees.

Here’s the feedback that we received from our trainees who had attended the session…

References

• How to generate a Certificate in Kubernetes
• Kubernetes Dashboard: An Overview, Installation, and Accessing
• Kubernetes for Beginners
• Kubernetes Security for Beginners

Next Task For You

Begin your journey towards becoming a Certified Kubernetes Security Specialist [CKS] by joining our FREE CLASS. You will also know more about the Roles and Responsibilities, Job opportunities for K8s security specialists in the market.