A question one often gets when working with enterprise customers deploying or moving containerized workloads to the Cloud is “What is the cloud provider responsible for and what am I as the customer responsible for in terms of cloud and application security”. It is a shared responsibility where the operational burden of secure deployments is shared between both the customer and the cloud provider (AWS in this case). Let us consider the specifics of containerized deployments after first discussing the generic model. For our purposes, the cloud provider here is AWS but the principles I discuss below are broadly applicable across the industry spectrum.
Security and Compliance are shared responsibilities between the cloud provider and the customer. The benefits of such a shared model are that the overall operational burden can be shared between both the customer and the cloud provider depending on the type of architecture chosen from the various compute, network, and storage options the cloud provider offers. As shown in the below diagram, AWS not only manages the security of the physical facilities but also components ranging from hardware, virtualization platform as well as the operating system.
The customer is then responsible for the management of the OS itself including updates and security patches, as well as application software as well as security groups, firewall, DNS etc. What this means is that the architecture of the application matters a great deal to its security maintenance. Customers should carefully evaluate the services they incorporate into the application as well as the integration between those services into their existing IT environment. The other prong to all this is to applicable regulatory and compliance framework & other laws in the industry vertical they operate in. Examples include PCI DSS, FedRamp, SOC ½, HIPAA etc.
The easiest way to remember the model of shared responsibility is that the cloud provider is responsible for the security “of” the cloud while the customer is responsible for security ‘in’ the cloud. This is broadly true when you are deploying applications into a cloud provider. Then there are nuances based on how much IaaS management one wants to do. In the case of AWS, customers have the option of using one of two runtimes – the standard EC2 which is customer self managed, or Fargate which is a serverless compute option. Fargate is managed in that it obviates the need for customers to provision or manage servers. Customers simply specify the resources their K8s workloads need in terms of CPU, Mem, Network etc in the form of a Fargate profile. At runtime, pods are scheduled only based on the profiles that match.
So, when a customer deploys containerized applications to the cloud, two different models are possible based on the runtime option (EC2 or Fargate) chosen as shown below.
Security Considerations Between Self Managed Workers vs Fargate vs Managed Node Groups
The shared responsibility model of cloud security describes Kubernetes security in two parts – security of the cloud and security in the cloud:
- Security of the cloud – As the cloud provider, AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. Now from a Kubernetes standpoint, assuming the customer is deploying Amazon EKS, AWS is responsible for the Kubernetes control plane, which includes the control plane nodes and the etcd database. When customers deploy managed node groups or Fargate as opposed to self managed workers, AWS then secures the underlying compute host instances used to run the customers pods. The customer is then responsible for IAM, pod security policies,network security, etc.
- Security in the cloud – From a granular standpoint, the customer’s responsibility then includes –
- Security group configuration that controls traffic from the EKS control plane into the VPC, the security groups etc
- Node and container configuration
- Node OS maintenance including patches and updates
- External Security software:
- IDSs
- IPSs
- DevSecOps
- Industry compliance including FedRamp, PCI, SOX, HIPAA etc
This blog discussed the line of separation from a security standpoint when deploying your application to the cloud. The next post in this series will focus on the fundamental aspects of Kubernetes security.