Understanding the roles of Workload Identities, Cluster Service Accounts, IAM Policies, and IAM Roles in managing access controls within AWS environments.
Exploring real-world use cases to illustrate the importance of effective IAM policy management in securing multi-tenant environments and aligning access controls with business requirements.
Comparing manual IAM policy management with streamlined approaches, such as Wayfinder's Package Workload Identities, to highlight the benefits of automation and centralised policy management.
Last week I published a blog, “How to spot gaps in your Public Cloud Kubernetes Security Posture” with the aim of providing a very high-level view of where security matters in public cloud Kubernetes.
Originally I intended to provide information for people new to Kubernetes and a few people have asked for some context to the blog, so here’s the introduction that was cut out of the original blog!
Tesla was hacked because their Kubernetes administrative console was not password protected. In another incident, Capital One left their AWS firewall definitions too lax and 30GB of credit application data (affecting 106 million customers) was exposed. Aside from implementing Kubernetes itself, the single most important consideration is security.
Roughly 60% of Kubernetes security breaches are due to misconfiguration (State of Kubernetes Security 2021).
More than any other technology area, public cloud has always had the capability of introducing unseen vulnerabilities, particularly through shadow IT, and the ease with which services are available to be consumed by development teams and end users.
Do you actually know if your organisation is using or planning to use public cloud Kubernetes? Do you understand what this means in terms of protecting the organisation's applications and data?
The above diagram is the premise for the article “How to Spot Gaps in Your Public Cloud Kubernetes Security Posture“ which aims to show just some of the areas that you need to consider, it’s a never-ending challenge keeping up to speed. Especially when presented with paradigm-shifting technology that is obtuse and pervasive, because it will be pervasive, and if you are not already armed with the high-level information about attack vectors and vulnerability maps that is needed to understand the security posture that you want to take.
If you already understand Kubernetes and containers, then great. You don’t need to be an expert in containers and Kubernetes but understanding the basics is essential to be able to identify where to focus effort.
The simplified Kubernetes architecture above is the basis for understanding some of the security areas that need to be considered.
Take a look at these articles to get a high-level understanding of the technologies in question, with a focus on Linux containers and Kubernetes:
Kubernetes can be used anywhere, public cloud, private datacenter, Edge, etc. There is, however, a distinction we need to make when we want to use Kubernetes in a public cloud. We have a choice of using Kubernetes in two ways.
With a self managed Kubernetes platform, we may use the open source Kubernetes project as a starter or take a 3rd party Kubernetes distribution like Red Hat’s OpenShift or VMWare’s Tanzu and deploy to public cloud. Alternatively, we may make use of a public cloud’s native Kubernetes services.
Opensource, OpenShift and Tanzu give you ultimate control in building and managing Kubernetes clusters, it is up to you to install, manage and maintain all of the components in your platform and infrastructure that make up Kubernetes. You are responsible for managing the compute (servers), control plane (core services needed to run Kubernetes clusters), networking and storage.
The second choice is to use public cloud Kubernetes services. The big difference is that the cloud providers will manage and run the Kubernetes infrastructure and you only need to take care of using Kubernetes to deploy and run your container workloads.
Security and compliance are considered shared responsibilities when using a managed service like AKS/EKS/GKE. Generally speaking, the cloud provider is responsible for security "of" the cloud whereas you are responsible for security "in" the cloud.
The public cloud providers are responsible for management of the Kubernetes control plane. This includes the Kubernetes masters, the ETCD database, and other infrastructure necessary to deliver a secure and reliable service. As a consumer of public cloud Kubernetes services, you are largely responsible for everything else e.g. IAM, pod security, runtime security, network security, and so forth.
Take a look at a great article talking about shared responsibility: How to Take "Shared Responsibility" of Cloud Security
So this was a really short introduction to the differences between public cloud Kubernetes and 3rd party and open source distributions of Kubernetes. Now head over to “How to Spot Gaps in Your Public Cloud Kubernetes Security Posture” blog to get a full picture of where security matters in public cloud.
