Kubernetes Architecture and Decisions for Adoption in regards to Security of Microservices in Cloud

From a graphical standpoint its easy to see the control plane as being multiple components the idea of microservices is splitting these services up to be infrastructure independent and for the most part it is important to understand this as you’re organization is considering moving to kubernetes.

Multiple approaches to adoption can be determined by a few questions your organization should strategize.

  • Are we well positioned to take advantage of orchestration? Such as what type of containers are you running that require orchestration, can your application operate such as (lift and shift)? Or does your custom applications need new logic built into it or refactoring?
    • What existing visibility/monitoring tools are you leveraging for your current application? How are you measuring SLI’s / SLO’s its likely you’ll want to understand responses and metrics that affect your performance. A popular tool you see in this space are tools such as Datadog, Prometheus and a number of ohters.
  • Do you need control of the Container Network Interface? This is going to factor into decisions on what capabilities or features you’d like to use while the CNI can be a limitation depending on the platform if your running managed clusters on a cloud service provider. You can still run your own cluster if your organization has the technical depth (I personally rarely encounter a org with multiple kubernetes experts) however, this is likely to shift as more organizations are looking for orchestration in cloud-native ecosystem.
  • Access control, if your going to be running anything in production you should start with a holistic approach on what access you’re willing to grant and how does the segmentation work such as can we use a policy engine? Or are we going to use some limited just in time access – this can start being cumbersome depending how you set this up and is a current challenge thinking of OSS companies are addressing this in multiple fashion a few examples would be Teleport project https://github.com/gravitational/teleport or you could use a CNCF graduated project such as https://spiffe.io/
  • Security Practitioners not only need to understand the basics but the architecture behind micro services but the interactions between the API’s in order to consider attacks and existing vectors you’ll see a variety of tools that are in this space notable are known such as Sysdig Falco, OPA, Kyverno as well to see what kind of use cases that are addressed you can think of these as a combination of security when we are thinking about defense in depth.

Recommendations

  • If your organization is going to adopt kubernetes ensure that you are running through various check list and following best practices outlined by CISA and NSA here https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF
  • When it comes to managed or unmanaged while you gain more control in unmanaged is your organizations skills aligned with this? Take a good inventory of what would be needed if you’d like to go on this path you could always consider this shift later, AKS/EKS/GKE are all robust solutions that are managed in the sense upgrades are much more streamlined, visuals such as GUI is typically easier for most users.
  • Lock down the access control to the Kube-API Server utilize a Cloud Native Application Protection Platform so you can centralize the security of the cluster a number of organizations have multiple vendors and this is likely a space you will see more integration a free tool or open source would be a tool such as Deepfence Threat Mapper this visually presents your cluster in a graphical user face as shown below
  • Defender for Cloud also provides Kubernetes protection and visibility to your cloud clusters if you are hosting your repositories in Azure Container Registry you can also leverage image scanning to know about vulnerabilities prior to pushing them out.
  • Ensure you understand the limitations of existing native support of kubernetes this is a evolving ecosystem that is on stable version 1.25 and continuously growing, for any shortfalls that can’t address your concerns consider external vendors that have solutions that can be more tailored to your specific use case. Project Calico also is a organization that leverages strong network policies that can be applied cluster-wide and provide isolation for your pods more granular.
  • This won’t cover every aspect of security for your adoption but should serve as a reference to get you started on making decisions to cloud native adoption.