When microservice oriented applications are deployed into Kubernetes orchestrated cloud platform, the security model works well in traditional enterprise application deployment workflow will face a lot of new challenges and needs to be transformed and microservice friendly also.
To achieve end to end application level security needs coordination between different components within your cloud cluster: From platform software bootstrapping, operation system installation, system software patching and upgrade, user authentication and authorization, certificate management, network policy, application traffic rate limiting, policy agent, ingress and egress traffic control to name a few.
Start from platform software and keep it updated
Using technologies such as secure boot with signed operation system image, secured container images repository and signed docker application images to bootstrap your platforms within the cluster. Keep it secure and away from vulnerable security hacking by constantly updating and patching your whole cloud platform infrastructure. Deploy HA enhanced control plane to increase overall Kubernetes cluster availability. Use CEPH CSI backend to enhance data availability in your cluster.
Monitor your cluster system containers, application containers, storage, computing and networking resource utilization, performance with toolset such as ELK stack to warn, log and debug possible cluster system and application level issues.
Keep your certificate and secret safe
There are a lot of certificates used in the modern Kubernetes cluster: Kubernetes root CA, docker image repository CA, ETCD root CA, multiple system application root CA and so on.
Keep those CA and Kubernetes clusters secret safe using ways such as TPM hardware, Key Management System (KMS) to store the key remotely and encrypt your system disk, kubernetes system database content to avoid physically stolen hardware information leak.
Expire and renew those certificates periodically with the help of open source solutions such as certificate manager.
Deploy suitable user and account authentication and authorization mechanism
RBAC is the fundamental mechanism to achieve user, group and internal service account authentication and related authorization. You can define roles, cluster roles and bind those roles with certain users, groups and internal service accounts used by pods when those are deployed.
PSP (Pod Security Policy), its replacement: PSS(Pod Security Standard) and OPA (Open Policy Agent) can be used to enforce the security policies before a Pod can be allowed to be deployed into the cluster.
Control cluster network traffic with network policies
Besides the pod security policy, user and user group authentication and authorization, network policy can be used to control its network traffic behaviors: allow some kind of network TCP/UDP of certain ports, deny some of network traffic in both ingress, egress direction.
Decouple application with underlining network layer functions using service mesh
Service mesh can be used to decouple the application logics and its underline networking layer related control and monitor functions, such as rate limiting, service call trace, mTLS security realization.
Others
Besides above, other must-have mechanisms to secure your cluster includes using secured, trusted application container image repositories, signed container images, and highly available infrastructures to name a few.
Summary
There are multiple ways to secure your cluster. Balancing the security rigidness and ease of use is a real challenge in day by day cluster operation.
Knowledge, Experience and Learning 