Google.iam.admin.v1.deleteserviceaccount

​

Event Information

• Event meaning & scope
  • google.iam.admin.v1.DeleteServiceAccount is emitted when a service account in a GCP project is deleted via IAM API, Console, gcloud, or Terraform.
  • The principal who performed the delete, the target service account (serviceAccount.* resource), and the time of deletion are captured in the Cloud Audit Logs (Admin Activity).
• Security & compliance implications
  • Deleting a service account can break workloads (its keys and associated access are effectively revoked), and may be used to cover tracks after misuse.
  • For SOC 2, ISO 27001, PCI DSS, HIPAA, etc., this event should be monitored as a privileged IAM change and retained according to your log retention policy.
  • Use it to verify that service account deletions follow approved change processes and least-privilege principles.
• Practical monitoring & controls
  • Create log-based metrics and alerts on protoPayload.methodName="google.iam.admin.v1.DeleteServiceAccount" scoped to sensitive projects or high-privilege service accounts.
  • Restrict who can delete service accounts by tightly controlling iam.serviceAccountAdmin / iam.serviceAccountDeleter-like roles and using custom roles where possible.
  • Periodically review these events to reconcile against your CMDB / IaC definitions and detect unauthorized or out-of-band deletions.

​

Examples

• Loss of access to critical workloads or data
  • Deleting a service account used by production services (e.g., GKE nodes, Cloud Run, CI/CD pipelines, backup jobs) can instantly break authentication to GCS, BigQuery, or databases, causing outages and potential data unavailability (impacting availability requirements in ISO 27001 / SOC 2).
• Privilege re-creation and audit gaps
  • If a highly privileged service account (e.g., with roles/owner or broad custom roles) is deleted without proper change control, an attacker could re-create an identically named account and regain excessive privileges while confusing audit trails (violating least privilege and traceability requirements like in PCI DSS and CIS GCP).
• Breakage of security controls and logs
  • Deleting service accounts tied to security tooling (e.g., SIEM forwarders, DLP scanners, Cloud Security Command Center integrations) can stop log export, monitoring, or scanning, creating blind spots in detection and incident response (contrary to NIST 800-53 AU*, IR* controls).

​

Remediation

​

Using Console

• Identify impact and restore access (availability & continuity)
  • In GCP Console, go to IAM & Admin → Audit Logs, filter for protoPayload.methodName=("google.iam.admin.v1.IAM.DeleteServiceAccount") and time of incident to identify the deleted service account(s), who deleted them, and affected projects.
  • Check workloads that are failing (e.g., Kubernetes Engine → Workloads, Cloud Run → Services, Cloud Functions, Cloud Scheduler, Cloud Build, BigQuery, Cloud Storage) for service account references and error messages (e.g., 401/403, “principal not found”).
  • If the service account was soft-deleted (within 30 days):
    • Go to IAM & Admin → Service Accounts → Deleted tab.
    • Select the service account → Restore.
    • Verify that roles on the service account still exist under IAM & Admin → IAM; re-attach any missing roles (prefer scoped, least-privilege roles).
• Recreate safely and re-bind permissions (least privilege & traceability)
  • If the service account cannot be restored (past 30 days or permanently removed):
    • Go to IAM & Admin → Service Accounts → + CREATE SERVICE ACCOUNT.
    • Use a new unique ID/name; do not reuse the old email/ID exactly if you suspect compromise (to avoid audit confusion). If reusing the name is required for application config, document this in a formal change record.
    • Assign only the minimum required roles via IAM & Admin → IAM → GRANT ACCESS (avoid roles/owner, roles/editor; favor granular roles like roles/storage.objectAdmin, roles/bigquery.dataEditor, etc.). Use Conditions where possible (e.g., restrict by resource or time).
  • Update workloads to use the new service account:
    • GKE: In Kubernetes Engine → Workloads, edit deployment → set Workload Identity / node SA appropriately; redeploy.
    • Cloud Run: Open service → EDIT & DEPLOY NEW REVISION → choose the new Service account → deploy.
    • Cloud Build / CI/CD: In Cloud Build → Settings and any triggers, update the Service account.
    • Backups / schedulers: In Cloud Scheduler, Backup solutions, and any custom jobs, update the configured service account.
  • Document the change in your change management system, link to audit log entries, and ensure this aligns with ISO 27001 / SOC 2 change control and PCI DSS logging requirements.
• Protect security tooling and implement preventive controls (logging, IR & policy)
  • Validate security- and logging-related service accounts:
    • Check Logging → Logs Router, Security → Security Command Center, SIEM exports, DLP scanners, and custom exporters for broken sinks or disabled connectors due to missing service accounts; re-point them to the restored/new accounts and verify logs are flowing.
  • Implement prevention using org policies and IAM:
    • In IAM & Admin → Organization Policies, enable and configure policies like constraints/iam.disableServiceAccountKeyCreation and constraints/iam.allowedPolicyMemberDomains as needed; consider using VPC-SC for critical projects.
    • Use IAM Recommender and Policy Analyzer (IAM → Recommendations / Policy Troubleshooter) to reduce over-privileged accounts and align to CIS GCP.
    • For critical service accounts, use Service Account Impersonation instead of keys, and restrict who can delete or manage service accounts (e.g., only tightly controlled admin group).
  • Add detective controls:
    • In Cloud Monitoring → Alerting, create alerts on Audit Log filters for: deletion of service accounts, changes to high-privilege roles, and modifications to log sinks or SCC integrations, mapped to NIST 800-53 AU*/IR* controls.

​

Using CLI

• Immediate containment & recovery (availability / change control)
  • List deleted SAs and impacted resources, then restore bindings where possible:
    • gcloud iam service-accounts list --project PROJECT_ID --format="table(name,disabled)"
    • Check audit logs for deletions:
      gcloud logging read 'resource.type="project" AND protoPayload.methodName="google.iam.admin.v1.IAM.DeleteServiceAccount"' --project=PROJECT_ID --limit=50 --format=json
  • If the original key material or workload identity isn’t recoverable, create a new SA, re-apply least-privilege roles, and update all workloads to use it:
    • gcloud iam service-accounts create NEW_SA --display-name="Replacement for prod SA"
    • gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:NEW_SA@PROJECT_ID.iam.gserviceaccount.com" --role="roles/storage.objectViewer"
  • For production/backup/SIEM SAs, validate end-to-end app connectivity and backup/restore jobs; document the change to meet ISO 27001/SOC 2 change-management requirements.
• Prevent privilege re-creation & enforce least privilege (PCI DSS / CIS / NIST AC)*
  • Disable, rather than delete, high-privilege SAs to preserve identity and audit history:
    • gcloud iam service-accounts disable SA_NAME@PROJECT_ID.iam.gserviceaccount.com
  • Create an Org Policy to restrict who can create/own SAs and assign high-privilege roles:
    • Example (YAML) to restrict SA admin:
      constraint: constraints/iam.allowedPolicyMemberDomains
      listPolicy:
        allowedValues:
        - under:organizations/ORG_ID
      
      Then apply:
      gcloud org-policies set-policy policy.yaml --organization=ORG_ID
  • Regularly enumerate SAs with broad roles and down-scope:
    • gcloud projects get-iam-policy PROJECT_ID --format=yaml | grep -A2 "roles/owner"
    • Replace roles/owner/overly broad custom roles with granular roles, and use CI/CD policy-as-code checks to block unauthorized role grants.
• Restore and harden security controls & logging (NIST 800-53 AU, IR)**
  • Identify SAs used by log sinks, SCC, DLP, and SIEM exporters, then verify they exist and are active:
    • gcloud logging sinks list --project=PROJECT_ID --format="table(name,destination,writerIdentity)"
    • gcloud iam service-accounts describe SA_NAME@PROJECT_ID.iam.gserviceaccount.com
  • If a security tooling SA was deleted, recreate with minimal required roles and rebind to sinks/integrations:
    • gcloud iam service-accounts create siem-forwarder --display-name="SIEM Forwarder"
    • gcloud logging sinks update SINK_NAME --writer-identity="serviceAccount:siem-forwarder@PROJECT_ID.iam.gserviceaccount.com"
  • Implement guardrails so security/logging SAs cannot be deleted without break-glass approval: use IAM Conditions and separate admin roles, and continuously monitor DeleteServiceAccount / ServiceAccountKey.Delete events via log-based metrics and alerts.

​

Using Python

• Prevent deletion of critical service accounts (SA) via IAM / Org Policy guardrails
  • Tag / label production and security SAs, then deny their deletion using Org Policy and IAM conditions (aligns with ISO 27001 A.8, SOC 2 CC5, CIS GCP).
  • Example: enforce constraints/iam.allowedServiceAccountDeletion (or equivalent org policy / custom automation) and require a change-control label like change_ticket for exceptions.
• Continuously detect & auto-remediate risky SA deletions (Python + Cloud Logging)
  • Create a log-based sink on DeleteServiceAccount events and route to a Cloud Function / Cloud Run that runs Python to:
    • Alert (e.g., Pub/Sub → email/Slack),
    • Optionally auto-recreate the SA (with restricted baseline roles, not owner),
    • Create a JIRA / ticket for formal review (supports PCI DSS 10, NIST AU/IR).
  • Example Python (for Cloud Function using Pub/Sub trigger on DeleteServiceAccount audit logs):

import base64
import json
from googleapiclient.discovery import build
from google.oauth2 import service_account

PROJECT_ID = "YOUR_PROJECT_ID"
# Optional: pre-defined baseline roles instead of owner
BASELINE_ROLES = [
    "roles/logging.logWriter",
    "roles/monitoring.metricWriter",
]

def parse_deleted_service_account(data):
    proto_payload = data.get("protoPayload", {})
    auth = proto_payload.get("authenticationInfo", {})
    req = proto_payload.get("request", {})

    # Preferred: from request body
    sa_email = req.get("name", "")  # e.g. projects/PROJECT_ID/serviceAccounts/SA_EMAIL
    if sa_email.startswith("projects/"):
        sa_email = sa_email.split("/")[-1]
    return sa_email

def recreate_service_account(sa_email):
    # sa_email: e.g., "my-sa@my-project.iam.gserviceaccount.com"
    if "@" not in sa_email:
        return

    project_id = sa_email.split("@")[-1].split(".iam.gserviceaccount.com")[0]
    iam = build("iam", "v1")

    sa_id = sa_email.split("@")[0]  # accountId
    name = f"projects/{project_id}"

    body = {
        "accountId": sa_id,
        "serviceAccount": {
            "displayName": f"Auto-recreated: {sa_id}",
            "description": "Recreated after delete; review roles & usages before production use."
        }
    }

    try:
        iam.projects().serviceAccounts().create(name=name, body=body).execute()
        return True
    except Exception as e:
        # If already exists or permission denied, log & continue
        print(f"Failed to recreate SA {sa_email}: {e}")
        return False

def ensure_baseline_roles(sa_email):
    crm = build("cloudresourcemanager", "v1")
    policy = crm.projects().getIamPolicy(
        resource=PROJECT_ID,
        body={"options": {"requestedPolicyVersion": 3}}
    ).execute()

    bindings = policy.get("bindings", [])
    sa_member = f"serviceAccount:{sa_email}"

    modified = False
    for role in BASELINE_ROLES:
        binding = next((b for b in bindings if b["role"] == role), None)
        if not binding:
            binding = {"role": role, "members": []}
            bindings.append(binding)
        if sa_member not in binding["members"]:
            binding["members"].append(sa_member)
            modified = True

    if modified:
        policy["bindings"] = bindings
        crm.projects().setIamPolicy(
            resource=PROJECT_ID,
            body={"policy": policy}
        ).execute()

def publish_alert(message: str):
    # Implement Pub/Sub, email, or ticketing integration here
    print(f"ALERT: {message}")

def handle_delete_event(event_data):
    sa_email = parse_deleted_service_account(event_data)
    if not sa_email:
        return

    # 1) Recreate SA (for critical SAs only – enforce allowlist/labels in practice)
    recreated = recreate_service_account(sa_email)

    # 2) Attach minimal baseline roles, NOT owner
    if recreated:
        ensure_baseline_roles(sa_email)

    # 3) Alert & require manual review for privileges re-creation (PCI DSS 7, CIS)
    publish_alert(
        f"Critical service account deleted and auto-remediated: {sa_email}. "
        f"Verify IAM roles, usages, and audit logs immediately."
    )

def entry_point(event, context):
    # Cloud Function entry point
    if "data" not in event:
        return
    payload = base64.b64decode(event["data"]).decode("utf-8")
    log_entry = json.loads(payload)
    handle_delete_event(log_entry)

• Harden lifecycle & compliance: least-privilege, backups, and traceability
  • Maintain IaC (Terraform, Deployment Manager) for all SAs and their roles; treat SA deletion as a controlled change with approvals (SOC 2 CC7, ISO A.12).
  • Regularly export IAM policies and SA definitions to secure storage (e.g., GCS with Object Versioning) for quick recovery and audit.
  • For SAs used by SIEM / DLP / SCC, implement health checks (e.g., log export volume, scanner heartbeats) and alert on anomalies to detect broken security controls (NIST 800-53 AU-6, IR-5).