XEIZE
/Vulnerability documentation/IaC/Ansible/GCP/GKE cluster configuration enables legacy ABAC

GKE cluster configuration enables legacy ABAC

Legacy ABAC in GKE adds permissions beyond IAM and RBAC. Prepare the required permissions, disable ABAC, and verify access on the actual cluster.

Description

ABAC means attribute-based access control. In GKE, legacy ABAC gives identities such as service accounts, nodes and controllers static permissions beyond those granted by IAM or RBAC. Narrowing RBAC bindings alone does not remove these additional permissions. Google recommends disabling ABAC and managing access with IAM and RBAC. ABAC is disabled by default in current GKE clusters and cannot be enabled in Autopilot.

Potential impact

  • Identities can be allowed to perform more operations than intended by IAM and RBAC. If an affected user's or service account's credentials are compromised, unnecessary additional permissions can increase the impact.
  • Authentication and authorization are separate. Enabling ABAC alone does not demonstrate that anyone on the internet can access the cluster without authenticating.
  • Disabling ABAC before replacing permissions that depend on it can interrupt access for operators, workloads or automation. Identify the required permissions first.

Remediation

  1. Check the actual ABAC setting and the identities and operations that need access. Prepare the necessary IAM permissions and RBAC roles and bindings without copying excessive permissions. Review both systems because GKE can authorize an action through either IAM or RBAC.
  2. Keep legacy_abac.enabled set to false in new cluster configurations. For an existing cluster, use Google's supported change procedure. For example, after confirming the target project and location, disable ABAC with gcloud container clusters update and --no-enable-legacy-authorization, or with the setLegacyAbac API.
  3. Once the operation finishes, read the actual legacyAbac.enabled value and test that operators, service accounts and automation can still perform required operations. Also test that unnecessary operations are not allowed. Verify the change on the cluster, rather than only editing the configuration file.

Examples

Before

yaml
- name: create a cluster
  google.cloud.gcp_container_cluster:
    name: my-cluster
    initial_node_count: 2
    master_auth:
      username: cluster_admin
      password: my-secret-password
    node_config:
      machine_type: n1-standard-4
      disk_size_gb: 500
    location: us-central1-a
    project: test_project
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present
    legacy_abac:
      enabled: yes

After

yaml
- name: create a cluster
  google.cloud.gcp_container_cluster:
    name: my-cluster
    initial_node_count: 2
    master_auth:
      username: cluster_admin
      password: my-secret-password
    node_config:
      machine_type: n1-standard-4
      disk_size_gb: 500
    location: us-central1-a
    project: test_project
    auth_kind: serviceaccount
    service_account_file: /tmp/auth.pem
    state: present
    legacy_abac:
      enabled: no

Explanation:

  • Before: enabled: yes configures legacy ABAC to be enabled.
  • After: enabled: no expresses the intent to disable ABAC. Prepare the required IAM and RBAC configuration separately. For an existing cluster, follow the change procedure above and verify the result.
  • Both examples retain a username and password under master_auth. That basic authentication method was removed in GKE 1.19, so these are not complete deployment configurations for a current environment. The project, password and service-account file path also require review for the actual environment.

References

XEIZE DocumentationTechnical support