This post will form part of a Cilium series, and first we will take a look at their NetworkPolicies. In an age where cloud-native environments have become the norm, the intricate web of networking and security presents both challenges and opportunities. One technology that has emerged as a game-changer in this space is Cilium. Cilium is an open-source project designed to provide networking, security, and observability for cloud-native environments such as Kubernetes clusters and other container orchestration platforms.

Managing access to Kube-API via service accounts In the world of Kubernetes, we have two types of accounts that can interact with the Kube-API. We have the user accounts, these are us humans that will authenticate using a kube-config file, and then we have service accounts which are processes, and these guys run inside our pods. In the case where your application, which is running on a Kubernetes cluster, needs to interact with other Kubernetes objects, then our application can use this service account and its accompanying token, to retrieve the required information about the objects from the API.

It’s no secret that Kubernetes doesn’t come standard with a lot of security features enabled. PodSecurityPolicies (PSP) was essentially a big security component, albeit not enabled by default, and very clunky, but if used correctly, it played a big part in ensuring that your pods adhere to a specific security standard. Since Pod Security Policy’s deprecation (version 1.21) a lot of businesses that utilize Kubernetes has raced to find a suitable replacement.

The need for a private cluster will be different for every company, but the most common requirement stems from a security point of view. As developers, architects and Ops teams become more comfortable with Kubernetes and its complexities, we’ll see more and more applications (that fit containerized environments) be pushed to Kubernetes clusters. It’s this rise in popularity that also brings malicious activity to the ecosystem. To add another layer of security to our platform we can ensure our cluster is private.

When it comes to securing your Kubernetes clusters, and the applications that run within it, there aren’t a lot of security features enabled ‘out-of-the-box’. This isn’t necessarily a bad thing. This ensures that the amount of work required to get your first application up and running remains minimal. But when we’re past the testing and development phase, we (of course) get to production. And that’s where the real fun starts.

A series about server hardening… This series is probably going to evolve as we progress through it, with modern methods of serving applications (containers), a series on how to secure an Apache host doesn’t really seem fitting at this stage. For this chapter of the series we’ll start with SSH, and how we can secure our infrastructure. SSH does an OK job at being secure out-of-the-box, but there are a number of things we can tweak - and it’s strongly advised to do so - to increase the overall security posture of your environment.

Quick Links: Installation Of AWS CloudWatch Agent - Manual Installation Of AWS CloudWatch Agent - Systems Manager Monitoring; It’s that all-important component of a SysOps engineer’s core competencies. Monitoring assists in troubleshooting multi-component failures and assist in the effort to ensure uptime and reliability of your platform. When running your platform in the cloud, the out-of-box monitoring options will only get you that far… Ok, let’s fill that last sentence in with some more specific variables.