Overview of Cloud Native Security
The 4Cs of Cloud Native Security
4C is a security model for protecting cloud-native applications running in containerized environments such as Kubernetes.
Cloud
consists of the infrastructure that runs your cloud resources
foundational layer of any cloud-native deployment
Cluster
consists of the Kubernetes components making up the worker nodes and control plane
Container
comes in two forms: image-level security, and runtime security
Code
also known as the application layer
Cloud Provider and Infrastructure Security
This diagram shows the division between AWS and the customers responsibilities. This may vary depending on the service being offered/consumed (e.g. IAAS, PAAS, SAAS, FAAS). But the general rule of thumb is - the CSPs are responsible for the foundational infrastructure while customers are responsible on the application and data running on top of the infrastructure.
Here's another definition from Center for Internet Security (CIS) - The division of security for things like data classification, network controls, and physical security between the Cloud Service Provider (CSP) and the user (you) is known as the shared responsibility model for cloud security.
Security services may also varies depending on the cloud provider. Below are the links you can read to further understand how security works in different CSPs.
Alibaba Cloud
Amazon Web Services
Google Cloud Platform
IBM Cloud
Oracle Cloud Infrastructure
VMware vSphere
Isolation Techniques
Namespace
In Kubernetes, a Namespace provides a mechanism for isolating groups of API resources within a single cluster.
Access controls
The most important type of isolation for the control plane is authorization.
Role-based access control (RBAC) is commonly used to enforce authorization in the Kubernetes control plane, for both users and workloads (service accounts).
Quotas
Kubernetes workloads consume node resources, like CPU and memory. In a multi-tenant environment, you can use Resource Quotas to manage resource usage of tenant workloads.
Network Isolation
Pod-to-pod communication can be controlled using Network Policies.
Storage Isolation
For security and data-isolation, dynamic volume provisioning is recommended and volume types that use node resources should be avoided.
Node Isolation
Node isolation is another technique that you can use to isolate tenant workloads from each other. With node isolation, a set of nodes is dedicated to running pods from a particular tenant and co-mingling of tenant pods is prohibited.
Artifact Repository and Image Security
Artifacts and Images
Signing, Trust and Integrity
Encryption
Security for Containers
Keep host and container runtime up to date
Set a user instead of root
Limit capabilities (Grant only specific capabilities, needed by a container)
Prevent in-container privilege escalation
Be mindful of Inter-Container Connectivity
Use Linux Security Module (seccomp, AppArmor, or SELinux)
Limit resources (memory, CPU, file descriptors, processes, restarts)
Set filesystem and volumes to read-only
Integrate container scanning tools into your CI/CD pipeline
Workload and Application Code Security
Enforce Pod security standards (PSP) to ensure that Pods and their containers are isolated appropriately. You can also use Runtime Classes to define custom isolation if you need it.
Network policies let you control network traffic between Pods, or between Pods and the network outside your cluster.
Container Application Manifest
Prohibit container images that use the “latest” tag
Prohibit container images from specified registries
Prevent all containers from running as “root”
Ensure all containers specify cpu and memory limits
Require all ingresses to have TLS configured
Prevent services from creating external load balancer
Last updated