This article is part of a series.
- Part 1: This Article
Threat actors frequently find opportunities in complex software systems, and cloud-native systems are no exception. Defense-in-depth methodology, used by cloud-native security, separates the system into four tiers. The four Cs of cloud-native security are as follows.
Cloud
The infrastructure that powers your cloud resources makes up the cloud layer. Most infrastructure security is handled by the provider when you set up a server with a cloud service provider (CSP). You are in charge of setting up the services, protecting your data, and maintaining security, though.
Misconfigurations and automated assaults are two common security vulnerabilities affecting the cloud layer. Attackers can take advantage of configuration errors brought on by human error or carelessness, such as holding onto default settings or having lax access controls for the administration console. Automation is another tool that attackers can use to quickly launch attacks and scan for vulnerabilities.
Before deploying to production, correct setup can be ensured by adhering to CSP standards and routinely reviewing settings. Practices for infrastructure as code (IaC) can reduce misconfigurations as well. IaC is the industry standard for cloud development today, and it has the added advantage of assisting DevOps teams in making the most of their cloud deployments while maintaining security.
Cluster
The worker nodes and control plane that are made up of Kubernetes components make up the cluster layer. You safeguard your Kubernetes workloads at this layer. Components of Kubernetes employ encrypted communication and must mutually authenticate using TLS certificates.
The main Kubernetes interface, the kube-api-server, needs to be protected above all other parts. This server restricts access by default to HTTPS, but you can add authentication by using a third-party identity provider to further secure it. For API server authorization, organisations frequently use specialised role-based access control (RBAC) rules, allowing you to manage the cluster and its workloads without requiring Secure Shell access.
The use of customised admission controllers is a great illustration of cluster security. Validating admission controllers in Kubernetes can be used to deny erroneous requests that are made to the Kubernetes API server. For instance, you can deny all privileged Pods using a validation admission controller.
Container
The container layer is made up of container images, which you can check for vulnerabilities in. Organizations frequently ignore problems including weak privilege setups, the usage of untrusted sources, and image security. To reduce exposure from known vulnerabilities, it’s critical to routinely update containers. Each programme that is currently executing in your containers should be scanned and verified.
Make sure any image you use was created by a reputable source or was obtained from a reliable registry. You can help ensure that container content originates from reliable sources by using an image signing tool like Docker Content Trust (DCT).
Furthermore, you should continuously scan each of your container images for known security flaws. You can’t merely identify application vulnerabilities or flaws in the framework and programming language you used by scanning your container images. Even the underlying operating system used in the container as well as any component that is a part of the container image can be found to have vulnerabilities. Again, there are several tools available to scan container images for vulnerabilities. The tools offered by AquaSec, Qualys, and Snyk are extremely popular (which is also seamlessly integrated with Docker Desktop and accessible via the docker scan command).
Code
The highest level of security control is offered by the code layer, commonly referred to as the application layer. To mitigate security threats, you can impose restrictions on exposed endpoints, ports, and services. TLS encryption should be used to secure communication between internal and external services.
Insecure code, poor risk assessments, and vulnerabilities in third-party software dependencies are examples of common security problems at the code layer. To quickly find unsafe coding practises and identify insecure code, you should use a static code analysis (SCA) tool. To ensure resistance to attacks like cross-site request forgery (CSRF) and cross-site scripting, regularly scan and test your applications.