-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug in google_binary_authorization_policy can silently disable binauthz #14929
Comments
Hey @melinath, passing this along. I tried to reproduce but couldn't the the deployment of I kept receiving the following error durring deployment
provider "google-local" {
project = "my-project"
}
resource "google_container_analysis_note" "note" {
provider = google-local
name = "tf-test-1"
attestation_authority {
hint {
human_readable_name = "My Attestor"
}
}
}
resource "google_binary_authorization_attestor" "attestor" {
provider = google-local
name = "tf-test-11"
attestation_authority_note {
note_reference = google_container_analysis_note.note.name
}
}
resource "google_binary_authorization_policy" "policy" {
provider = google-local
admission_whitelist_patterns {
name_pattern = "gcr.io/google_containers/*"
}
default_admission_rule {
evaluation_mode = "ALWAYS_ALLOW"
enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
}
cluster_admission_rules {
cluster = "us-central1-a.prod-cluster"
evaluation_mode = "REQUIRE_ATTESTATION"
enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
require_attestations_by = [google_binary_authorization_attestor.attestor.name]
}
global_policy_evaluation_mode = "ENABLE"
} |
@benhoskings using below config, I tested by adding more entries in resource "google_binary_authorization_policy" "policy" {
admission_whitelist_patterns {
name_pattern = "gcr.io/google_containers/*"
}
default_admission_rule {
evaluation_mode = "ALWAYS_ALLOW"
enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
}
cluster_admission_rules {
cluster = "us-central1-a.prod-cluster"
evaluation_mode = "REQUIRE_ATTESTATION"
enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
require_attestations_by = [google_binary_authorization_attestor.attestor2.name,
google_binary_authorization_attestor.attestor.name,
google_binary_authorization_attestor.attestor3.name,
]
}
}
resource "google_container_analysis_note" "note" {
name = "issue9216"
attestation_authority {
hint {
human_readable_name = "My attestor"
}
}
}
resource "google_binary_authorization_attestor" "attestor" {
name = "issue9216"
attestation_authority_note {
note_reference = google_container_analysis_note.note.name
}
}
resource "google_binary_authorization_attestor" "attestor2" {
name = "issue9216-2"
attestation_authority_note {
note_reference = google_container_analysis_note.note.name
}
}
resource "google_binary_authorization_attestor" "attestor3" {
name = "issue9216-3"
attestation_authority_note {
note_reference = google_container_analysis_note.note.name
}
} In my case, I see below in the plan which is different from yours.
I have tested the same version of the provider as what you have (v4.63.1), same result. Even if I use direct attestor id (below) instead of the reference, I still see the similar plan which is replacement on
I wonder how to repro your plan |
@benhoskings using your config, it doesn't work for me as the cluster is required. Did you hit that error? |
@benhoskings my terraform version was 1.5.1. I have also tried v1.4.5. The result is the same in which replacement is planned on cluster_admission_rules Can you share your debug log? |
@edwardmedia Our config uses the
That's a required field within the |
I can confirm that this behavior exists. Specifically, adding an attestor to
|
I found that the resource's update method is getting called with a set built from here, which only contains the new elements and not all elements in the config. I think this is a bug with the SDK. It's also possible that hashicorp/terraform-plugin-sdk#157 is related. |
I can also confirm the behaviour. Starting with a policy requiring the resource "google_binary_authorization_policy" "policy" {
default_admission_rule {
evaluation_mode = "REQUIRE_ATTESTATION"
enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
require_attestations_by = [
"projects/sdbx/attestors/foo-attestor",
"projects/sdbx/attestors/bar-attestor", # added this attestor
"projects/sdbx-2/attestors/baz-attestor", # added this attestor
]
}
project = var.project_id
} But the plan looks like this Terraform will perform the following actions:
# google_binary_authorization_policy.policy will be updated in-place
~ resource "google_binary_authorization_policy" "policy" {
id = "projects/sdbx"
# (1 unchanged attribute hidden)
~ default_admission_rule {
~ require_attestations_by = [
- "projects/sdbx/attestors/foo-attestor",
+ "projects/sdbx/attestors/bar-attestor",
+ "projects/sdbx-2/attestors/baz-attestor",
]
# (2 unchanged attributes hidden)
}
}
Plan: 0 to add, 1 to change, 0 to destroy.
Updating the resource to look like this (missing the foo-attestor) $ gcloud container binauthz policy export
defaultAdmissionRule:
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
evaluationMode: REQUIRE_ATTESTATION
requireAttestationsBy:
- projects/sdbx-2/attestors/baz-attestor
- projects/sdbx/attestors/bar-attestor |
Community Note
modular-magician
user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned tohashibot
, a community member has claimed the issue already.Terraform Version
Affected Resource(s)
google_binary_authorization_policy
Terraform Configuration Files
The issue
We've hit a bug with the
google_binary_authorization_policy
resource. When adding entries todefault_admission_rule.require_attestations_by
, we've found that they replace existing entries rather than being created alongside them. This causes the existing binary authorization protections to be removed without any indication that it's happening.This is a serious security issue. Applying a plan that appears correct will have the effect of silently disabling binary authorisation until the target is applied again.
This issue has been reported before here: #9216 but it wasn't addressed or noticed as far as I can see, so I'm creating a fresh ticket with current details, logs, etc.
Reproduction
Specifically, we started with a policy containing two attestors,
a
andb
, as shown above. When we add a third,c
, to the list, we get the following plan, which is correct:However, applying that plan generates the following request (provider.terraform-provider-google_v4.63.1_x5):
After applying this plan, the cloud console will show
c
has been added to the list buta
andb
have been removed.(The resource names above are simulated but the details are accurate otherwise.)
The text was updated successfully, but these errors were encountered: