Back
Google Cloud Platform (GCP) is one of the TOP recognized cloud platform that shares the first place with AWS and Azure. Many online services choose its Kubernetes Engine (GKE) and other services to host applications and infrastructure. We see how it is difficult to achieve the security in the legacy projects. Especially if the security was not built into them from the very beginning. So what areas should consider the security specialists in the GCP/GKE stack?
Prevent human errors
One of the biggest source of the risk is just a typo, e.g. human error. We have seen hundred-page deployment manuals where it was so easy to miss something and leave the system unprotected. As a solution use automated deployment with the aid of Terraform. This is a golden standard for repeatable infrastructure in the cloud.
Secure the project level
One of the resource units in GCP is a project. Split your infrastructure into several projects and keep the minimum rights for developers there. Also, you should not have connections between the staging/prod projects at all. Use the compliance engine like "Falco" to watch for the important project and infrastructure attributes.
Secure the network
Keep the minimal external network service exposure. Thanks to the rich features of modern cloud technologies, you can afford that. Look at these cases:
- if you have a service on the GKE for some internal purposes, connect to it with 'kubectl port-forward'. No need to publish it.
- for Cloudflare use Argo tunnel technology, which allows not to have any external IP.
- if you still need to publish the service, use the white listing: white list of the IP addresses that are allowed to connect to the Kubernetes master node; white list of the IP addresses that are allowed to connect to ingress Kubernetes object. And so on.
- Use Pub/Sub to exchange the messages between the components.
Keep track of access
While this is mostly an administrative control, it is very important. Just keep track of all access between the users, systems, components. It is very hard to fully revoke the access, so be aware about that.
- For VMs track user access through the password and SSH keys.
- For different service objects consider access through user credentials and service tokens.
- For GKE keep track of Kubernetes users.
- And for sure do not hardcode any passwords/keys in the application code.
Whenever possible reduce your attack surface - get rid of VMs, use GKE. Or even better - use Google functions for any stateless functionality.
We have a rich experience securing GCP/AWS//Azure clouds. Contact our sales team whenever you need any kind of audit or security operations service.