I've been conducting a long-term evaluation of Prisma Cloud's Compute module, specifically focusing on its compliance-as-code and automated remediation capabilities within our Kubernetes and cloud infrastructure. The promise of auto-remediation for critical misconfigurations, such as publicly accessible cloud snapshots (RDS, EBS, etc.), is a significant operational draw, theoretically aligning with GitOps principles where the deployed state is continuously reconciled with a secure desired state.
We enabled targeted auto-remediation for a specific policy: "Unencrypted Amazon RDS snapshot is publicly accessible." Our initial approach was cautious, applying it to a development account with a known set of non-critical resources. The remediation action is configured to be "Delete public snapshot," which essentially makes the snapshot private. The mechanics, as I understand them, involve Prisma Cloud's backend invoking the cloud provider's SDK (in this case, AWS `modify-db-snapshot-attribute`) with parameters to revoke public access.
**Key observations and potential pitfalls:**
* **Timing and Race Conditions:** The remediation runs on its own schedule, detached from your CI/CD pipeline. We observed a scenario where a Terraform apply (managing RDS instances and subsequent manual snapshots) would create a snapshot, and before our internal tooling could apply tags or adjust permissions, Prisma Cloud's scanner would flag it and the subsequent remediation job would execute. This isn't a break, per se, but it creates a conflict if your IaC or other processes expect to manage that attribute.
* **Lack of Contextual Awareness:** The system treats the policy as a binary gate. It does not consider whether the public snapshot was intentional (e.g., for a limited-time, cross-account data share facilitated by a separate, just-in-time process). A hard auto-remediation would break such workflows. This necessitates very precise, granular policy targeting using labels/account IDs, moving beyond simple policy enablement.
* **Operational Logging:** The logs within Prisma Cloud are clear about the action taken. However, integrating this event into our central logging (Splunk) and alerting (PagerDuty) required additional API work. The out-of-the-box notifications were insufficient for our SRE response playbooks.
* **Terraform State Drift:** This is the most critical point for IaC purists. If Prisma Cloud modifies a resource outside of Terraform's management, it creates state drift. On the next `terraform plan/apply`, Terraform will detect that the `public` attribute no longer matches its state file and will attempt to re-apply the public setting, recreating the violation and triggering the loop again.
A simplified, hypothetical Terraform state conflict loop:
```hcl
resource "aws_db_snapshot" "test" {
db_instance_identifier = aws_db_instance.main.id
db_snapshot_identifier = "test-snapshot"
shared_accounts = ["*"] # Public, as defined in IaC
}
```
Prisma Cloud remediation removes `"*"` from `shared_accounts`. Next Terraform plan:
```
~ update in-place
Terraform will perform the following actions:
# aws_db_snapshot.test will be updated in-place
~ resource "aws_db_snapshot" "test" {
~ shared_accounts = [] -> ["*"]
}
```
My question to the community is multifaceted: Have you implemented this in production, and how did you solve for the IaC state drift issue? Did you couple Prisma Cloud's alerts with a custom remediation workflow that instead creates a pull request to modify the underlying Terraform code, adhering to GitOps? Or have you found success in using Prisma Cloud's own Terraform Cloud integration to manage this reconciliation? I'm particularly interested in patterns that avoid the breakage of legitimate, albeit ephemeral, public snapshot use cases.