Enable Cloud Security Command Center

More Info:

Enable Cloud Security Command Center (Cloud Scc) To Provide A Centralized View Of Security For Your Gke Clusters.

Risk Level

Low

Address

Security

Compliance Standards

CIS GKE
Reserve Bank of India (RBI) Master Direction – Information Technology Framework

Triage and Remediation

Remediation

Remediation

Manual Steps

Confirm SCC API and service enablement for the org/project
- On any machine with gcloud and Org Admin / Security Admin rights, run:
```
gcloud services list --enabled \
  --project=YOUR_PROJECT_ID \
  | grep securitycenter
```
- Also check at org level (replace with your org ID):
```
gcloud organizations get-iam-policy ORGANIZATION_ID \
  --format="json(bindings)" | jq '.bindings[] | select(.role | contains("roles/securitycenter"))'
```
- If the securitycenter.googleapis.com API is not enabled or no SCC roles are assigned, SCC is effectively not in use.
Verify Security Command Center activation and tier in console
- In Google Cloud console (any browser, user with Security Center Admin or Org Admin):
  1. Go to Security → Security Command Center at the org level.
  2. Confirm that SCC is On and note the tier (Standard/Premium).
  3. If SCC is Off or not initialized, follow the setup prompts (organization scope, billing, and tier selection) per the quickstart.
Check that GKE-related sources are enabled in SCC
- In the console, under Security → Security Command Center → Settings → Sources / Integrations:
  1. Confirm that built‑in detectors relevant to GKE/Kubernetes (e.g., Container Threat Detection, Kubernetes security posture/anomaly detectors if part of your tier) are enabled.
  2. For each disabled GKE-related integration, decide whether to enable it based on your risk profile and licensing.
Ensure SCC has coverage for the GKE projects/folders
- In the console, under Security Command Center → Settings → Scope:
  1. Verify the organization / folder / project hierarchy monitored by SCC includes the projects that host your GKE clusters.
- From CLI, list folders/projects under SCC’s org for confirmation:
```
gcloud projects list --filter="parent.id=ORGANIZATION_ID" --format="table(projectId, name)"
```
- If any GKE project is outside the monitored scope, adjust SCC scope to include it (or move the project into a monitored folder/org as per your governance model).
Validate that SCC is ingesting GKE security data
- On any machine with gcloud and appropriate Security Center roles, list recent active findings for one GKE project:
```
gcloud scc findings list "organizations/ORGANIZATION_ID/sources/-" \
  --location=global \
  --filter='resource.project_display_name="YOUR_PROJECT_NAME"' \
  --limit=10 \
  --format="table(name, category, state, event_time)"
```
- If you see no findings at all over time while detectors are enabled and clusters are active, investigate SCC configuration further (log routing, detectors, permissions).
Document and, if needed, complete SCC setup following quickstart
- If any of the above checks show SCC not enabled, mis-scoped, or missing GKE-related detectors, complete setup using the quickstart at the given URL, ensuring:
  - SCC is enabled at the organization level.
  - Appropriate Security Center roles (e.g., roles/securitycenter.admin, roles/securitycenter.findingsViewer) are assigned to security/Ops teams.
  - GKE projects are within SCC scope and GKE-related integrations are turned on.
- Re-run step 5 to confirm that SCC is now actively collecting security findings for your GKE environment.

Using kubectl

kubectl cannot enable or configure Cloud Security Command Center because this control resides in the GCP organization/project security settings, not in Kubernetes API objects. Perform the remediation in the cloud provider console/CLI/IaC as described in the Manual Steps section.

Automation

#!/usr/bin/env bash
#
# Audit Cloud Security Command Center (SCC) enablement for GKE clusters in a GCP project.
# REQUIREMENTS:
#   - gcloud CLI installed and authenticated
#   - IAM permissions:
#       securitycenter.settings.get
#       container.clusters.list
#
# USAGE:
#   ./check_scc_gke.sh PROJECT_ID
#
# NOTES:
#   This does NOT change any configuration. It only reports state.
#   It checks:
#     1) Whether SCC is generally enabled for the org/project.
#     2) Whether the GKE Security Posture integration is enabled per cluster
#        (a primary way SCC surfaces GKE security data).

set -euo pipefail

if [[ $# -ne 1 ]]; then
  echo "Usage: $0 PROJECT_ID" >&2
  exit 1
fi

PROJECT_ID="$1"

# ------------- Helper: check org / project SCC onboarding -------------

echo "=== Checking SCC onboarding state for project: ${PROJECT_ID} ==="

# Get the organization ID that owns this project
ORG_ID="$(gcloud projects get-ancestors --project "${PROJECT_ID}" \
  --format='value(id)' \
  | tail -n1 || true)"

if [[ -z "${ORG_ID}" ]]; then
  echo "WARNING: Could not determine organization for project ${PROJECT_ID}."
  echo "SCC is an organization-level service. Verify in the Cloud Console:"
  echo "  Security > Security Command Center > Settings"
else
  echo "Organization ID: ${ORG_ID}"
  echo
  echo "-> SCC service enablement (organization-level):"
  gcloud scc settings describe "organizations/${ORG_ID}" \
    --project="${PROJECT_ID}" \
    --format='table(name, onboarding_state, service_enablement_state)' || {
      echo "ERROR: Failed to describe SCC organization settings."
    }

  cat <<'EOF'

Interpretation:
  - onboarding_state:
      - ONBOARDED or ENABLED-like states: SCC is generally enabled.
      - ONBOARDING_STATE_UNSPECIFIED, NOT_ONBOARDED, or similar: SCC not fully enabled.
  - service_enablement_state:
      - ENABLED / ENABLED_FOR_ORG: SCC service is active.
      - DISABLED / NOT_ENABLED: SCC not providing findings.

Any state indicating NOT_ONBOARDED / DISABLED means SCC is effectively not enabled
for the org and therefore not providing centralized security visibility for GKE.
EOF
fi

# ------------- Helper: list GKE clusters and check Security Posture -------------

echo
echo "=== Enumerating GKE clusters and checking Security Posture / SCC integration ==="
echo

# List all GKE clusters in the project (all regions/zones)
CLUSTERS_JSON="$(gcloud container clusters list \
  --project="${PROJECT_ID}" \
  --format='json(name,location,releaseChannel.channel,securityPosture,resourceLabels)' || true)"

if [[ -z "${CLUSTERS_JSON}" || "${CLUSTERS_JSON}" = "[]" ]]; then
  echo "No GKE clusters found in project ${PROJECT_ID}."
  exit 0
fi

echo "${CLUSTERS_JSON}" | jq -r '
  [
    .[] |
    {
      name: .name,
      location: .location,
      releaseChannel: (.releaseChannel.channel // "UNSPECIFIED"),
      postureStatus: (.securityPosture.state // "UNSPECIFIED"),
      postureMode: (.securityPosture.config.mode // "UNSPECIFIED"),
      labels: (.resourceLabels // {})
    }
  ] |
  (["CLUSTER","LOCATION","RELEASE_CHANNEL","POSTURE_STATE","POSTURE_MODE","LABELS"] | @tsv),
  (.[] | [ .name, .location, .releaseChannel, .postureStatus, .postureMode, ( .labels | tojson ) ] | @tsv)
' | column -t

cat <<'EOF'

Interpretation per cluster:
  - POSTURE_STATE:
      - ACTIVE / ENABLED-like: GKE Security Posture is running and can feed SCC.
      - DISABLED / DEPRECATED / UNSPECIFIED: posture findings may not be available in SCC.
  - POSTURE_MODE:
      - ENABLED / STRICT / STANDARD (depending on your config): posture checks are applied.
      - DISABLED / UNSPECIFIED: posture checks not enforced or not configured.

Clusters with POSTURE_STATE of DISABLED / UNSPECIFIED or POSTURE_MODE of DISABLED / UNSPECIFIED
are effectively not contributing full security posture data to SCC.

These outputs indicate a POTENTIAL PROBLEM for this benchmark when:
  - SCC onboarding_state or service_enablement_state is NOT_ONBOARDED / DISABLED.
  - Any production GKE cluster has Security Posture in a DISABLED / UNSPECIFIED state or mode.

Because this control is MANUAL, you must review:
  - Whether SCC should be enabled organization-wide.
  - Whether each GKE cluster that requires centralized security visibility should have
    Security Posture enabled and integrated with SCC.

Remediation cannot be fully automated from this script; enablement must be
done via the Cloud Console, gcloud, or IaC per organizational policy.
EOF

Additional Reading:

https://cloud.google.com/security-command-center/

More Info:​

Risk Level​

Address​

Compliance Standards​

Triage and Remediation​

Remediation​

Additional Reading:​