Ensure Access To OCI Audit Service Log For OKE

Manual Steps

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

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:

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

Verification (on any machine with OCI CLI access): rerun the audit-style check to confirm access to OCI Audit logs for OKE is functioning:

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.

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.

Automation

#!/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

OCI Misconfigurations

Ensure Access To OCI Audit Service Log For OKE

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation