Google CloudOverview
In Kubernetes, authorizers interact by granting a permission if any authorizer grants the permission. The legacy authorizer in Kubernetes Engine grants broad, statically defined permissions. To ensure that RBAC limits permissions correctly, you must disable the legacy authorizer. RBAC has significant security advantages, can help you ensure that users only have access to cluster resources within their own namespace and is now stable in Kubernetes.
Rationale
Enable Legacy Authorization for in-cluster permissions that support existing clusters or workflows. Disable legacy authorization for full RBAC support for in-cluster permissions. In Kubernetes, RBAC is used to grant permissions to resources at the cluster and namespace level. RBAC allows you to define roles with rules containing a set of permissions.
Remediation guidance
Using Console
- Go to Kubernetes GCP Console by visiting https://console.cloud.google.com/kubernetes/list?
- Select reported Kubernetes clusters for which Legacy Authorization is enabled
- Click on EDIT button and Set 'Legacy Authorization' to Disabled
Using Command Line
To disable Legacy Authorization for an existing cluster, run the following command:
gcloud container clusters update \[CLUSTER_NAME\] --zone \[COMPUTE_ZONE\] --no-enable-legacy-authorization
Impact
Once the cluster has the legacy authorizer disabled, you must grant your user the ability to create authorization roles to ensure that your role-based access control permissions take effect.
Default Value
Kubernetes Engine clusters running Kubernetes version 1.8 and later disable the legacy authorization system by default, and thus role-based access control permissions take effect with no special action required.
References
- https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control?hl=en_US
- https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-container-cluster
Notes
On clusters running Kubernetes 1.6 or 1.7, Kubernetes service accounts have full permissions on the Kubernetes API by default. To ensure that your role-based access control permissions take effect for a Kubernetes service account, you must create or update your cluster with the option --no-enable-legacy-authorization. This requirement is removed for clusters running Kubernetes version 1.8 or higher.
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Legacy Authorization is set to Disabled on Kubernetes Engine Clusters
Connectors
Covered asset types
Expected check: eq []
gkeClusters(where:{legacyAbacEnabled_NOT:false}){...AssetFragment}
