> ## 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 Access To OCI Audit Service Log For OKE

### More Info:

The OCI Audit service log captures API activity for OKE and is essential for security monitoring and incident investigation. Ensure access to these audit logs is available.

### Risk Level

High

### Address

Security

### Compliance Standards

* CIS OKE

### Triage and Remediation

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

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. On any machine with OCI CLI access (can be outside the cluster), confirm Audit logs are enabled tenant‑wide (they are on by default) by listing recent events for the compartment that contains your OKE cluster:
           ```bash theme={null}
           oci audit event list \
             --compartment-id <OKE_COMPARTMENT_OCID> \
             --start-time "$(date -u -d '-2 hours' +%Y-%m-%dT%H:%M:%SZ)" \
             --all
           ```
           Ensure that results are returned and include `com.oraclecloud.containerengine` events.

        2. On any machine with OCI Console access (web browser), verify you can view Audit logs:
           * Open: Menu → Logging & Monitoring → Audit.
           * Set the Compartment to the one containing the OKE cluster.
           * Set a recent time range (e.g., last 2 hours).
           * Confirm events appear and that you can filter on `Service = Container Engine for Kubernetes`.

        3. On any machine with OCI CLI access, ensure at least one principal (group or dynamic group) used by your security/operations team has permission to read Audit logs for the OKE compartment. Example to test an existing principal’s access using `--auth security_token` or configuration for that user:
           ```bash theme={null}
           oci audit event list \
             --compartment-id <OKE_COMPARTMENT_OCID> \
             --start-time "$(date -u -d '-2 hours' +%Y-%m-%dT%H:%M:%SZ)" \
             --profile <SECOPS_PROFILE> \
             --all
           ```
           If this fails with an authorization error, update IAM policies in the OCI Console (Menu → Identity & Security → Policies) to include a statement such as:
           ```
           allow group <secops-group-name> to read audit-events in compartment <OKE_COMPARTMENT_NAME>
           ```

        4. On any machine with OCI Console access, optionally configure longer‑term retention or export for audit logs:
           * For retention: Menu → Logging & Monitoring → Audit → Tenancy → Configure, and adjust retention (if option available in your tenancy).
           * For export: Menu → Developer Services → Service Connectors → Create service connector to route Audit as source → Object Storage / Logging / Streaming as target.

        5. On any control plane node (host shell via SSH), record evidence locally (for change tracking) that access to Audit logs is verified for OKE by saving a small report:
           ```bash theme={null}
           mkdir -p /var/log/oke-audit-check
           oci audit event list \
             --compartment-id <OKE_COMPARTMENT_OCID> \
             --start-time "$(date -u -d '-1 hours' +%Y-%m-%dT%H:%M:%SZ)" \
             --all > /var/log/oke-audit-check/last-audit-events.json 2>&1
           ```

        6. Verification (on any machine with OCI CLI access): rerun the audit-style check to confirm access to OCI Audit logs for OKE is functioning:
           ```bash theme={null}
           oci audit event list \
             --compartment-id <OKE_COMPARTMENT_OCID> \
             --start-time "$(date -u -d '-1 hours' +%Y-%m-%dT%H:%M:%SZ)" \
             --all | jq -r '.[].data | select(.resourceName | contains("cluster") or .additionalDetails.service = "containerengine")' | head
           ```
           Successful output with OKE‑related events confirms the requirement is met.
      </Accordion>

      <Accordion title="Using kubectl">
        kubectl cannot be used to configure or grant access to OCI Audit service logs, because this setting is managed at the OCI/OKE control-plane and tenancy level, not via Kubernetes API objects. Perform the required review and configuration in the OCI Console or your IaC for OKE as described in the Manual Steps section.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        #
        # CIS OKE 2.2.1 – Ensure Access To OCI Audit Service Log For OKE (MANUAL)
        #
        # Automation note:
        # The benchmark explicitly states: "No remediation is necessary for this control."
        # There is no host-level configuration change or deterministic fix to apply.
        # This script only assists by collecting basic context from each control plane node.
        #
        # Safe to run multiple times.

        set -euo pipefail

        echo "=== CIS OKE 2.2.1 – No automated remediation required ==="
        echo "This control is MANUAL and has no node-level fix."
        echo

        # Basic node/context information for your records
        echo "=== Node identity ==="
        hostname -f || hostname || true
        echo

        echo "=== Kubernetes node objects (for reference only) ==="
        # This requires kubectl config and RBAC; skip gracefully if not present.
        if command -v kubectl >/dev/null 2>&1; then
          kubectl get nodes -o wide || true
        else
          echo "kubectl not found on this node; skipping kubectl-based context."
        fi
        echo

        # Verification guidance (cannot be automated from the node):
        cat <<'EOF'
        === Verification (manual) ===
        CIS OKE 2.2.1 is satisfied by ensuring that you, as an operator, have access
        to the OCI Audit service logs for your OKE tenancy.

        From a workstation with OCI CLI or console access:

        1) Console path:
           - Sign in to the OCI Console.
           - Navigate: Observability & Management -> Logging -> Audit.
           - Select the Compartment where OKE is deployed.
           - Confirm you can view audit events for OKE resources (Cluster, Node Pool, etc.).

        2) OCI CLI example:
           - Identify the compartment OCID where OKE lives.
           - Then run:
               oci audit event list \
                 --compartment-id <compartment_ocid> \
                 --limit 5

           - Successful output of recent events confirms access to audit logs.

        There is no further host-level configuration to apply for this control.
        EOF
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>