Checks

Enabling a network policy allows the segregation of network traffic by namespace

In provider versions prior to 4: The attribute <code>workload_metadata_config.node_metadata</code> configures how node metadata is exposed to workloads. It should be set to <code>SECURE</code> to limit metadata exposure, or <code>GKE_METADATA_SERVER</code> if Workload Identity is enabled.

Starting with provider version 4: The attribute <code>node_metadata</code> has been removed. Instead, <code>workload_metadata_configuration.mode</code> controls node metadata exposure. When Workload Identity is enabled, it should be set to <code>GKE_METADATA</code> to prevent unnecessary exposure of the metadata API to workloads.

Automatic updates keep nodes updated with the latest cluster master version.

Enabling private nodes on a cluster ensures the nodes are only available internally as they will only be assigned internal addresses.

StackDriver logging provides a useful interface to all of stdout/stderr for each container and should be enabled for moitoring, debugging, etc.

Enabling authorized networks means you can restrict master access to a fixed set of CIDR ranges

You should disable Attribute-Based Access Control (ABAC), and instead use Role-Based Access Control (RBAC) in GKE.

RBAC has significant security advantages and is now stable in Kubernetes, so it’s time to disable ABAC.

Automatic repair will monitor nodes and attempt repair when a node fails multiple subsequent health checks

It is recommended to use Service Accounts and OAuth as authentication methods for accessing the master in the container cluster.

Basic authentication should be disabled by explicitly unsetting the <code>username</code> and <code>password</code> on the <code>master_auth</code> block.

Keys should be rotated on a regular basis to limit exposure if a given key should become compromised.

Using unmanaged keys makes rotation and general management difficult.

Secure boot helps ensure that the system only runs authentic software.

In GitHub Actions, one can authenticate to Google Cloud by setting values for workload_identity_provider and service_account and requesting a short-lived OIDC token which is then used to execute commands as that Service Account. If you don't specify a condition in the workload identity provider pool configuration, then any GitHub Action can assume this role and act as that Service Account.

Service accounts and user accounts used in IAM bindings should follow organization email policies (e.g., no personal emails).

Firewall rules should restrict RDP (TCP/3389) access to specific IP ranges. Open RDP access can be a security risk.

Firewall rules should restrict SSH (TCP/22) access to specific IPs. Open SSH can be a security risk.

Firewall rules should not be wide open to all ports. Lock down rules to only required ports.

Ensures that Google Cloud's default firewall rules are disabled, as they may be overly permissive and pose security risks. The default network comes with pre-populated firewall rules that allow broad access and should be replaced with more restrictive custom rules.

Firewall rules allowing broad port ranges can be risky. Ensure rules are as specific as possible.

Private Google Access allows instances in a subnet to reach Google APIs and services via internal IP, which should be enabled for private networks.

Flow logs for subnets should be enabled to capture network traffic details for security analysis.

Cloud Storage bucket access logs should be enabled for audit purposes.

Object versioning in Cloud Storage is recommended to protect against accidental or malicious deletions.

IAM Audit Logging should be configured for all services and the appropriate log types to track changes and accesses.