> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Confirm SCC API and service enablement for the org/project**
           * On any machine with `gcloud` and Org Admin / Security Admin rights, run:
             ```bash theme={null}
             gcloud services list --enabled \
               --project=YOUR_PROJECT_ID \
               | grep securitycenter
             ```
           * Also check at org level (replace with your org ID):
             ```bash theme={null}
             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.

        2. **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.

        3. **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.

        4. **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:
             ```bash theme={null}
             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).

        5. **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:
             ```bash theme={null}
             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).

        6. **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.
      </Accordion>

      <Accordion title="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.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/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
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>

### Additional Reading:

* [https://cloud.google.com/security-command-center/](https://cloud.google.com/security-command-center/)