Security in your infrastructure should be considered as a key thing. According to type of your business, your requirements can be more or less tightened, but you always should keep an eye on it.
Same thing is with kubernetes. There are many possibilities to keep your cluster secured. Probably using all of them is not always the best idea, but at least be aware of the below mentioned:
We have to types authorization and authentication in kubernetes.
Firstly for our application workload we should use Service Accounts (SA) object (and related to it Role, RoleBinding, ClusterRole, ClusterRoleBinding). To be more exact, we are forced to use service account, but implicit usage of SA ends up with admin privileges. This is that we should get rid of as soon as possible. Roles bind to the Service Account should be as narrow as possible.
On the other hand, there are operators, developers, admins. And this is a place where the OICD provider should come into play. There are other ways, like file based authentication, but it rather should not be considered.
You should never use container images from untrusted source. Please keep in mind that ANYONE can put containers to docker hub main repository. . Admins should have a full control of what containers are used in the cluster. To accomplish it use the private repository (like jfrog Artifactory, Nexus etc) and take advantage of remote (proxy) repository and mirrors configuration in docker. To be even more secured, use image scanning tool like Xray. Run your containers in context of non root user.
One of the drawback of the docker container is their ability to use of Host resources. For example you can create a pod with mounted docker socket from the host. Let’s imagine what would happen if by accident (bug) or deliberate action (malicious user) docker rm $(docker ps -a -q) command is executed.
To mitigate above danger you can consider:
You should take into consideration whether your services are exposed to public or not. In case of public usage you can think about placing those services on separate nodes.
Keep an eye on each master node component. Keep it secure according to official k8s installation guide.
Kubernetes has a secret object which was designed (or rather was supposed to) to keep your configuration secured. Using it you must be aware that it’s only base64 encoded. So it can be easily decoded by any user having permission to read secrets or perform exec to your pod.
To mitigate this security issue, you can use encryption providers.
You can use Network Policy object to restrict traffic inside kubernetes cluster
You can think about introducing one of the service mesh solution in your cluster. Istio is one of the most popular. Among others, it brings you end to end ssl support.