Blog

Securing Kubernetes Deployments on AWS

Kubernetes is open-source software that allows you to deploy and manage containerized applications at scale. Kubernetes can manage clusters on Amazon EC2 instances, run containers on those instances, and perform deployment, maintenance, and scaling tasks.

Kubernetes enables using the same set of tools to run containerized applications on-premises and in the cloud.

AWS provides Amazon Elastic Kubernetes Service (EKS), a managed, certified Kubernetes-compatible service with community-supported service integrations for running Kubernetes on AWS and on-premises.

Kubernetes is a project that is open source. Kubernetes enables you to run containerized applications wherever you want without changing your operational tools. Kubernetes is regularly maintained and improved by a large community of volunteers.

Kubernetes’ large community creates and maintains Kubernetes-compatible software that can be used to enhance and extend application architectures.

Kubernetes Security Best Practices on AWS

Understanding the Model of Shared Responsibility

When using managed services such as EKS, security and compliance are viewed as shared responsibilities. In general, AWS is responsible for “inside” cloud security, and the cloud customer is responsible for “inside” cloud security.

AWS manages the Kubernetes control plane through EKS. This includes the Kubernetes master server, the etcd database, and any other infrastructure that AWS requires to provide secure and reliable services.

Identity and access management (IAM), pod security, runtime security, and network security are primarily the responsibility of EKS customers.

AWS is also in charge of keeping Kubernetes patch releases and security patches up to date for EKS-optimised Amazon Machine Images (AMIs). Customers who use managed node groups (MNGs) must upgrade their node groups to the most recent AMI using the EKS API, CLI, Cloudformation, or the AWS console.

Red/Blue Team and Penetration Testing Practice

Divide the security personnel into two groups: red and blue. The red team investigates vulnerabilities in various systems, while the blue team handles vulnerability defence.

If you need more security personnel to form a separate team, consider hiring a third-party organization familiar with Kubernetes exploits.

Kubesploit is a penetration testing framework for conducting tests. It can simulate real-world attacks on Kubernetes clusters, allowing the blue team to practise responding to them and assess their effectiveness. You can attack your cluster regularly to find vulnerabilities and misconfigurations.

Auditing and Logging

Audit log collection and analysis can be beneficial for a variety of reasons.

Logs are useful for determining the root cause of production issues. When a sufficient number of logs are collected, they can also be used to detect abnormal behaviour. EKS transmits audit logs to Amazon Cloudwatch.

The EKS-managed Kubernetes control plane manages audit logs. Amazon provides instructions for enabling and disabling control plane logs for Kubernetes API servers, controller managers, and schedulers.

Scan Images for Vulnerabilities Regularly

Container images, like virtual machines, can contain vulnerable binaries and application libraries. The best way to avoid threats is to scan images regularly with an automated scanner.

Images in the Amazon Elastic Container Registry (ECR) can be scanned automatically or on demand (every 24 hours). Clair, an open-source image scanning solution, is currently used by ECR.

The results of the scan are written to EventBridge’s ECR event stream. The scan results can also be viewed in the ECR console. Vulnerabilities rated as HIGH or CRITICAL should be deleted or rebuilt. When an image that has been deployed becomes vulnerable, it should be replaced as soon as possible.

Network Governance

Pod-to-pod communication is enabled by default in a Kubernetes cluster. Although this flexibility is beneficial during development, it is not considered safe for production.

Kubernetes network policies allow you to limit network traffic between pods as well as between pods and external services. Kubernetes network policies cover layers 3 and 4 of the OSI model.

Network policies identify the source and destination pods using pod selectors and labels, but they can also include IP addresses, port numbers, protocol numbers, or a combination of these.

Key Takeaways:

These are some key takeaways on the basics of Kubernetes deployment and how to secure it on AWS:

➔     Understanding the shared responsibility model—When using managed services like EKS, security and compliance are considered shared responsibilities.

➔     Practise red/blue team and penetration testing—the red team investigates vulnerabilities in various systems, while the blue team defends against them.

➔     Auditing and logging—collecting and analyzing audit logs can help determine the root cause of production issues.

➔     At-rest encryption—Kubernetes provides three AWS native storage options that support data-at-rest encryption.

➔     Scan images for vulnerabilities regularly—vulnerable binaries and application libraries can be found in container images. The best way to avoid threats is to scan images with an automated scanner regularly.

➔     Network policies— identify the source and destination pods using pod selectors and labels.

We at Linux2cloud, hope this will be useful as you secure your Kubernetes deployment on AWS. For Kubernetes and AWS courses, contact us.