4 Pillars of Cloud-Native Security
Many enterprise IT organizations today rely on traditional security policies and tools that were not built to deal with the change, scale and complexity of cloud-native environments. While it’s hard to believe, for many organizations, security is an afterthought.
The rise of DevSecOps helped to shift container security left, but that’s not enough. Organizations have only begun to realize the complexity and security threats associated with cloud-native environments as they move beyond using containers and start using orchestrators, registries, service meshes, etc. throughout their cloud-native journey.
Enterprises must pay more attention to security threats related to cloud and, in particular, to cloud-native environments.
Traditionally, applications were hosted in a traditional data center owned or rented by the enterprise, and were deployed on particular (virtual) machines that were regularly accounted for and secured, to a certain degree. Today, enterprise systems are built on data centers enterprises don’t own (i.e., public clouds or colocation) leveraging open source platforms (i.e., Kubernetes) and using source code we didn’t write (i.e., third-party libraries). That, in and of itself, makes the attack surface of modern applications larger and the impact of a breach deeper.
For those reasons, a comprehensive security model that can address threats at every level must cover four pillars (aka the four Cs) of cloud-native security: code, container, cluster and cloud.
1. Code
It all starts with your source code. By preventing or catching security issues early in the software development life cycle (SDLC), you can save time, money and effort down the road.
One way to limit the vulnerabilities in your code is to use static code analysis (SCA). Usually, after writing and committing your code to a source code repository, an automated task trigger will start the static code analyzer.
Think of a static code analyzer as your code’s DNA scanner. It scans through your code, trying to figure out what it’s made of and generates a report of all the findings afterward. This has many advantages.
First, you better understand your codebase, especially when the number of lines is growing fast. Second, you detect some of the hardest-to-find defects, such as deadlocks and null pointers. Third, you identify and remediate vulnerabilities that are part of your code.
It’s highly recommended that you use a mix of static application security testing (SAST) and dynamic application security testing (DAST). That way, you prevent attacks commonly found in web applications such as SQL injection and cross-site scripting (XSS).
Also, make sure to adhere to security best practices, including not exposing unnecessary ports, using secure tunnels and scanning third-party libraries.
2. Container
Once your application is built inside a container, there are a few things you should look for wherever a container is built, stored and deployed.
First, you want to avoid running privileged containers. The majority of applications don’t require root access to operate, except for system containers like monitoring or logging agents. This should stop an attacker from gaining root access to the container and using it to access the host node (aka a container escape attack).
Second, you should consider strengthening container isolation. Typical Linux containers are not sandboxes by default, and are able to make system calls to the underlying host kernel freely. Some popular sandboxing tools include Seccomp, AppArmor and SELinux.
Next, perform image and container scanning. This involves scanning the container image at rest (i.e: in an image registry) and at runtime for vulnerabilities. This is a safeguard against any misconfigurations in the container image file or changes to the container at runtime.
Finally, consider image signing. That’s a mechanism that uses public key infrastructure (PKI) to make sure images have been not tampered with throughout the container life cycle.
3. Cluster
The cluster is to containers what rails are to trains. Therefore, it’s vital to keep clusters secured and operational so you can reap the rewards of running containers at scale.
You want to make sure the cluster’s components, as well as the applications running in the cluster, are secure. The following recommendations are for Kubernetes in particular, they also can be applied to other orchestrators.
For the cluster components, you want to consider the following:
- Encrypt all data at rest in the cluster’s data store (i.e., etcd)
- Rotate or renew certificates regularly
- Disable public access
- Limit administrative access
For the applications running in the cluster, there are many ways to reduce the damage that could be done in the event of a breach (aka the blast radius). Here are few things to consider:
- Limit traffic between applications in the cluster using network policies
- Secure external access to services (aka ingress) using TLS
- Use pod security policies to disallow privileged containers
- Control access to the API server in terms of who (authentication) and what (authorization)
Also, you want to make sure to consult the documentation of your cluster vendor or cloud provider to make sure you’re securing the cluster components, as well as the applications running in it, properly.
4. Cloud
The cloud, regardless of whether it’s public, private or hybrid, is where your application containers and platforms run, and is a critical part of the security equation. If the cloud layer is vulnerable or misconfigured in any way, this can do a lot of damage to the components built on top of it.
Major public and private cloud providers have security guidelines and best practices you should follow. Make sure to consult the documentation and use any tools specific to the provider or providers you partner with to reduce the attack surface, avoid misconfigurations and detect any possible threats early on.
Organizations that make security a priority and a collaborative effort thrive in adopting emerging technologies, driving innovation and delighting their customers while managing security risks.
Today, cloud-native technologies are becoming mainstream in the enterprise, and traditional security policies and tools of the past are not sufficient.