> ## 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.

# Ensure Logging And Cloud Monitoring Is Enabled

### More Info:

Enable Cloud Logging and Cloud Monitoring for the cluster so system and workload logs and metrics are collected for troubleshooting and security analysis. Missing telemetry hinders detection and response.

### Risk Level

Medium

### Address

Security

### Compliance Standards

* CIS GKE

### Triage and Remediation

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

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Gather current logging/monitoring configuration**
           * Run on any machine with gcloud access:
             ```bash theme={null}
             gcloud container clusters describe CLUSTER_NAME \
               --location LOCATION \
               --project PROJECT_ID \
               --format json | \
             jq '{loggingService: .loggingService, monitoringService: .monitoringService, loggingConfig: .loggingConfig, monitoringConfig: .monitoringConfig}'
             ```

        2. **Assess whether cluster-level services are enabled**
           * From the output, check `loggingService` and `monitoringService`.
           * If either is `none`, or not a Cloud Logging/Cloud Monitoring service, logging/monitoring is effectively disabled at the cluster level and should be corrected.

        3. **Assess which components are sending logs and metrics**
           * In the same JSON, review `loggingConfig.componentConfig.enableComponents` and `monitoringConfig.componentConfig.enableComponents`.
           * Confirm that at least control-plane and system components you rely on for security/troubleshooting (e.g., `SYSTEM_COMPONENTS`, `WORKLOADS`, `APISERVER`, etc.) are enabled per your logging/monitoring policy.

        4. **Decide desired telemetry coverage with stakeholders**
           * Based on your organization’s requirements (compliance, incident response, cost constraints), decide:
             * Which logging components to enable (e.g., `SYSTEM_COMPONENTS,WORKLOADS,APISERVER`)
             * Which monitoring components to enable (e.g., `SYSTEM_COMPONENTS,WORKLOADS`)
           * Document this as the target configuration for this cluster.

        5. **Apply the chosen configuration**
           * Run on any machine with gcloud access, replacing the comma‑separated lists with your chosen components:
             ```bash theme={null}
             gcloud container clusters update CLUSTER_NAME \
               --location LOCATION \
               --project PROJECT_ID \
               --logging=COMPONENT1,COMPONENT2,COMPONENT3
             ```
             ```bash theme={null}
             gcloud container clusters update CLUSTER_NAME \
               --location LOCATION \
               --project PROJECT_ID \
               --monitoring=COMPONENT1,COMPONENT2,COMPONENT3
             ```
           * Coordinate with operations: this changes control-plane telemetry but does not restart workloads.

        6. **Verify the change and basic data flow**
           * Re-run the audit command:
             ```bash theme={null}
             gcloud container clusters describe CLUSTER_NAME \
               --location LOCATION \
               --project PROJECT_ID \
               --format json | \
             jq '{loggingService: .loggingService, monitoringService: .monitoringService, loggingConfig: .loggingConfig, monitoringConfig: .monitoringConfig}'
             ```
           * Confirm `loggingService`/`monitoringService` and the enabled components match your decision, then spot-check in the Cloud Logging and Cloud Monitoring consoles that new logs and metrics are appearing for the cluster.
      </Accordion>

      <Accordion title="Using kubectl">
        kubectl cannot enable or configure Cloud Logging or Cloud Monitoring because these settings are managed at the GKE control-plane level via the Google Cloud console, gcloud CLI, or IaC. To remediate this finding, make the changes in the cluster configuration using those tools as described in the Manual Steps section.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        # Report GKE Cloud Logging & Monitoring configuration for all clusters in a project.
        # Usage: ./gke-logging-monitoring-audit.sh <GCP_PROJECT_ID>

        set -euo pipefail

        PROJECT_ID="${1:-}"

        if [[ -z "${PROJECT_ID}" ]]; then
          echo "Usage: $0 <GCP_PROJECT_ID>" >&2
          exit 1
        fi

        echo "Auditing GKE Logging and Monitoring configuration in project: ${PROJECT_ID}"
        echo

        # List all clusters (both zonal and regional)
        gcloud container clusters list \
          --project "${PROJECT_ID}" \
          --format="value(name,location)" | while read -r CLUSTER_NAME LOCATION; do

          if [[ -z "${CLUSTER_NAME}" || -z "${LOCATION}" ]]; then
            continue
          fi

          echo "===== Cluster: ${CLUSTER_NAME} | Location: ${LOCATION} ====="

          # Describe cluster and extract logging/monitoring configuration
          gcloud container clusters describe "${CLUSTER_NAME}" \
            --location "${LOCATION}" \
            --project "${PROJECT_ID}" \
            --format=json | jq '
              {
                name: .name,
                location: .location,
                releaseChannel: .releaseChannel.channel,
                loggingService: .loggingService,
                monitoringService: .monitoringService,
                loggingConfig: ( .loggingConfig // {} ),
                monitoringConfig: ( .monitoringConfig // {} )
              }'

          echo
        done
        ```

        Run from: any machine with `gcloud`, `jq`, and access to the GCP project.

        Problem indicators to look for in the output:

        * `loggingService` is `logging.googleapis.com/none` or empty.
        * `monitoringService` is `monitoring.googleapis.com/none` or empty.
        * For newer clusters using `loggingConfig` / `monitoringConfig`, required components (e.g. `SYSTEM_COMPONENTS`, `WORKLOADS`, `APISERVER`, etc.) are missing from the respective `*Config` fields.

        These conditions indicate that Cloud Logging and/or Cloud Monitoring is not fully enabled and need manual review and a decision on which components to enable, followed by the `gcloud container clusters update ... --logging=... --monitoring=...` commands as appropriate.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>