Skip to main content

More Info:

Cluster audit logs and security-relevant events should be captured without truncation or sampling so post-incident forensics, anomaly detection, and compliance evidence are reliable. Stream logs to a tamper-evident destination.

Risk Level

High

Address

Compliance, Logging, Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

Using Console

Below are console-only steps to ensure OKE captures all security‑relevant events without restriction using OCI Logging.This focuses on:
  • Enabling all available OKE control plane logs (API server, audit, scheduler, controller)
  • Ensuring logs are not filtered and are persisted appropriately

1. Open Your OKE Cluster

  1. Sign in to the OCI Console.
  2. In the left menu, go to Developer Services → Kubernetes Clusters (OKE).
  3. Select the Compartment where your cluster resides.
  4. Click the name of the cluster you want to fix.

2. Enable All Control Plane Logs

  1. On the cluster details page, go to the Logs tab.
  2. For each available log type (names can vary slightly by version/shape), do the following:
    • kube-apiserver or kubernetes API server
    • kube-apiserver audit / kubernetes API server audit
    • kube-controller-manager
    • kube-scheduler
    • Any other OKE control plane logs presented
    For each: a. If you see Enable log or Create log:
    • Click Enable log.
    • Choose or create a Log Group:
      • Prefer a dedicated group like oke-control-plane-logs in the same Compartment.
    • Make sure Log Type is set to Service Log.
    • Do not add any filters; keep the default to capture all events.
    • Click Enable or Create.
  3. Confirm that the Status for each key log is now Enabled.

3. Set Log Retention (No Restrictive Filters)

  1. Go to Observability & Management → Logging → Log Groups.
  2. Select the Compartment and choose the log group you used (e.g., oke-control-plane-logs).
  3. Open each OKE log you just enabled.
  4. In each log:
    • Click Edit Log.
    • Ensure there are no “Include/Exclude” filters configured. If filters exist, clear them so that:
      • All severities are captured.
      • All categories/paths are captured.
    • Set an appropriate Retention Period (e.g., 90 days or per your policy).
    • Save changes.
This ensures logs are not restricted at the log configuration level.
To make sure security‑relevant events are preserved and queryable:
  1. Go to Observability & Management → Service Connectors.
  2. Click Create Service Connector.
  3. Configure:
    • Source: Logging
      • Select the Compartment and Log Group used for OKE.
      • Do not configure any filter; select all the OKE logs.
    • Target:
      • Either Object Storage (for long‑term archival)
        • Choose/create a Bucket dedicated for audit/security logs
      • Or Logging Analytics (for search/analytics)
  4. Complete and Create the connector.
This avoids event loss and supports compliance use cases.

5. Verify Events Are Flowing

  1. Go to Observability & Management → Logging.
  2. Open the OKE log group and each log stream (API server, audit, etc.).
  3. Confirm:
    • New log entries appear when you perform actions on the cluster (e.g., kubectl create namespace, kubectl auth can-i).
    • Events show full detail (no indication of dropped or filtered events).

These steps ensure OKE is capturing all security‑relevant control plane events without restriction, with central logging and optional archival or analytics as required by most security benchmarks.
Below are CLI-focused steps to ensure OKE (OCI Container Engine for Kubernetes) captures all security‑relevant events (i.e., all available service logs) without restriction.
Assumptions:
– You have OCI CLI configured (oci setup config) with appropriate permissions.
– You know the OCID of your OKE cluster and your compartment.

1. Identify Required IDs

If you already have a log group, just set:

2. Discover All Available OKE Log Categories

You want all categories so you don’t restrict security‑relevant events.
Note the list of categories returned (examples, actual names may differ by region/version):
  • cluster
  • controlplane
  • apiserver
  • scheduler
  • controller-manager
  • audit
    etc.
You will create a log for each category you want captured.

3. Enable All OKE Service Logs (No Filtering)

For each category from step 2, create a service log associated with the OKE cluster and ensure it is enabled.Example Bash loop:
Key points:
  • --log-type "SERVICE" for service logs.
  • --is-enabled true ensures logging is active.
  • No filter/retention restriction is applied here; every event of each category is captured.

4. (Optional) Verify Logs Are Enabled and Active

Ensure all categories you care about are present and is-enabled is true.
OCI Audit is always on at the tenancy level, but ensure you are exporting them centrally:

This configuration ensures OKE control plane / cluster and tenancy audit events are captured via Logging without category‑based restriction, which aligns with the requirement that security‑relevant events be captured comprehensively.
Below is how you remediate “OCI OKE should capture security-relevant events without restriction” using Python and the OCI SDK, by enabling OKE service logs (especially audit) with no filters.

1. Prerequisites

  1. Install OCI SDK:
  1. Configure OCI CLI/SDK auth at ~/.oci/config:
  1. Collect:
  • compartment_ocid where the OKE cluster lives
  • cluster_ocid for the OKE cluster you want to fix

2. Python script to enable OKE audit (and other) logs without restriction


3. What this does (in terms of the requirement)

  • Creates (or reuses) a log group dedicated to OKE security logs.
  • Discovers the OKE logging service and its log categories.
  • For each security-relevant category (audit, etc.), creates a SERVICE log:
    • is_enabled=True
    • no log_filter configured → all events in that category are captured (no restriction).
  • Ensures existing logs are enabled if they were disabled.
If you paste the output of list_services / list_log_categories for your tenancy, I can adjust the exact security_categories for your environment.
This change does not replace the existing oci_containerengine_cluster resource; it only adds logging and streaming resources around it.To verify, terraform plan should show:
  • + creation of oci_logging_log_group.OKE_LOG_GROUP
  • + creation of oci_logging_log.OKE_CLUSTER_ALL_LOGS with is_enabled = true and category = "all"
  • + creation of oci_objectstorage_bucket.OKE_LOG_ARCHIVE_BUCKET (if included)
  • + creation of oci_sch_service_connector.OKE_LOG_SERVICE_CONNECTOR (if included)
  • ~ no changes to oci_containerengine_cluster.OKE_CLUSTER.