Security Best Practices in GKE — Part 1

By Yasirhashmi．Jan 24, 2023

Google Kubernetes Engine (GKE) is a fully-managed, highly-scalable, and secure container orchestration service in Google Cloud. However, as with any system, there are certain security best practices that we should follow to ensure that our GKE deployments are as secure as possible.

This article is part of a multi-part series covering below best practices around securing GKE workloads:

1. Enable Network Policies in GKE
2. Role based access control (RBAC) in GKE
3. Workload Identity
4. Binary Authorization
5. PodSecurity — Hardening GKE clusters

In the first part of this series, we will cover network policies and RBAC

1. Enable Network Policies

GKE Network Policies allow us to configure how groups of pods are allowed to communicate with each other and other network endpoints.

Policies are defined in YAML files and are applied to specific namespaces or to individual pods. A network policy consists of a set of ingress and egress rules that define the allowed traffic.

Ingress rules define incoming traffic and egress rules define outgoing traffic. Each rule has a set of match conditions, and an action that is applied to traffic that matches those conditions. The action can either allow or deny the traffic.

Benefits of Network Policies:

• Increased security: By defining rules for communication between pods, Network Policies can help to reduce the attack surface of the network and prevent unauthorized access to the data.
• Improved isolation: Network Policies allows to isolate different parts of the network, such as production and development environments, to reduce the risk of accidental data breaches or misconfigurations.
• Easier troubleshooting: With Network Policies, we can easily identify which pods are allowed to communicate with each other and which are not. This can make it easier to troubleshoot network issues and identify potential security risks.

Network Policy enforcement:

Network policy enforcement in GKE is enabled by default for Autopilot clusters. However, for standard clusters, we have to enable them manually under Networking=> Enable Kubernetes Network Policy

However, GKE Dataplane V2 comes with Kubernetes network policy enforcement built-in and hence the option to enable Kubernetes Network policy is disabled.

To define a Network Policy, we will need to specify at least a podSelector, which selects the set of pods the policy should be applied to, and a list of ingress/egress rules.

By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace.

Here is an example of a simple NetworkPolicy that allows all incoming traffic and all outgoing traffic:

Policy Manifest:

This policy will be applied to all pods in the ‘default’ namespace that have the label ‘role: db’, and it allows all incoming traffic to these pods and all outgoing traffic from these pods.

We can also specify match conditions for incoming and outgoing traffic to selectively allow or deny traffic. For example, we can allow incoming traffic from pods with specific labels, or we can allow outgoing traffic to specific IP ranges.

Let’s suppose we have a multi-tier application running on our GKE cluster that consists of a web frontend, a set of application servers, and a database. The web frontend and application servers need to be able to access the database, but we don’t want any other pods in the cluster to be able to access the database directly.

To achieve this, we can create a Network Policy that only allows incoming traffic to the database pods from the web frontend and application server pods.

Policy Manifest:

In this example, the policy applies to all pods in the “my-app” namespace that have the label “app: my-db”. It allows incoming traffic only from pods that have the labels “app: my-web” and “app: my-app-server”. All other incoming traffic will be denied.

Note that we can also add the Egress rule in case we want to restrict the outbound traffic from the above selected pods.

This is just a simple example of what can be accomplished with Kubernetes Network Policies. There are many other use cases, including securing communication between different namespaces, allowing or denying specific IP ranges, and more.

For example,

Let’s suppose we have a pod running a service that should only be accessible from a specific IP range. We can create a Network Policy that allows incoming traffic to that pod only from the specified IP range.

Policy Manifest:

This policy will apply to all pods in the “my-app” namespace that have the label “app: my-service”. It allows incoming traffic only from IP addresses in the range of 10.0.0.0/16, except for IP addresses in the range of 10.0.1.0/24

We can also use IP addresses in egress rules to restrict outgoing traffic from pods. For example, we can create a policy that allows pods to connect only to specific external IP addresses or ranges.

Policy Manifest:

This policy will apply to all pods in the “my-app” namespace that have the label “app: my-service”. It allows outgoing traffic only to IP addresses in the range of 10.0.0.0/8

It’s very important to test the Network Policy before applying it to the production environment, as misconfigured policies can cause disruptions to the communication between services and can lead to unpredictable behaviors.

2. Enable Role based access control (RBAC) in GKE

Role-Based Access Control (RBAC) is a built-in feature in Kubernetes that allows us to control access to the Kubernetes API based on the roles and permissions of individual users, groups or service accounts.

Using RBAC, we can grant different levels of access to different users or Google groups, based on their role within the organization, which helps to ensure that only authorized users or Google groups are able to perform certain actions within the cluster.

Benefits of RBAC:

• Increased security: By defining roles and permissions for users and service accounts, RBAC can help to reduce the attack surface of your cluster and prevent unauthorized access to your data.
• Improved auditing: RBAC allows you to easily track who is accessing your cluster and what actions they are performing. This can make it easier to identify potential security risks and compliance issues.
• Easier management: With RBAC, you can easily manage access for multiple users and teams across your organization. This can make it easier to scale your environment and ensure that access is properly controlled.

To illustrate, let’s suppose we have a team of developers that is responsible for deploying and managing applications on our GKE cluster. We want to give them access to the Kubernetes API so that they can perform actions such as creating and updating pods and services, but we don’t want them to have access to sensitive resources such as secrets and cluster-level resources such as nodes.

To achieve this, we can create a Role that grants the developers the necessary permissions to perform their job and a RoleBinding that assigns that role to the developers.

For example,

1. Create a role with name as developers:

This role grants the developers the ability to perform all actions (get, list, watch, create, update, patch, and delete) on pods and services in all namespaces.

2. Create a role-binding named developers-binding:

This binding assigns the developers role to the developers group.

With this configuration, developers will have the ability to perform all actions on pods and services in all namespaces, but they will not have access to other resources such as secrets, or cluster level resources such as nodes.

Another use case can be when we have multiple teams with different responsibilities. We can create role and rolebindings accordingly and assign them to different teams.

For example, we have a team that takes care of monitoring, we can create a role named monitoring-role with permissions to access metrics, logs and other monitoring-related resources. Then create a rolebinding monitoring-rolebinding and assign the monitoring-role to the team ‘monitoring-team’.

Conclusion

In conclusion, Network Policies and Role based access control (RBAC) are important security features in Google Kubernetes Engine (GKE) that can be used to control access to resources within a cluster. Network policies allow administrators to define rules on how pods can communicate with each other and to external resources while RBAC policies allow fine-grained control over who has access to specific resources and what actions they are allowed to perform.

Together, these features can help to secure a GKE cluster and ensure that only authorized users and pods are able to access resources.

---

The original article published on Medium.