Skip to content

OCI Native Ingress Controller (OKE managed add-on) flagged by Cloud Guard for missing probes and resource limits #138

@amaanx86

Description

@amaanx86

Description

Summary

Oracle Cloud Guard is consistently reporting multiple Container Security findings against the OCI Native Ingress Controller that is deployed as an OKE managed add-on. These findings relate to missing health probes and resource requests/limits on the controller’s containers.

Since this is a managed add-on, end users cannot safely modify the Deployment spec, yet the issues remain open in Cloud Guard and affect security/compliance posture.

I am running on the latest supported OKE/Kubernetes version and the latest native ingress controller add-on available in my region.


Reported Problems

Cloud Guard is flagging the following on the native ingress controller workload:

  • Container without readiness probe
  • Container without liveness probe
  • Container without CPU requests
  • Container without CPU limits
  • Container without memory requests
  • Container without memory limits
Image

All are reported with Medium risk under Container Security / Container Workloads.


Affected Resource (Redacted)

  • Type: OKE Cluster (managed)
  • Component: oci-native-ingress-controller Deployment
  • Namespace: native-ingress-controller-system
  • Region: KSA (Jeddah)
  • Cluster: [redacted]

Why this is a concern

  1. Operational reliability

    • Lack of liveness/readiness probes can impact availability and automated recovery.
  2. Resource governance

    • Missing requests/limits can lead to noisy-neighbor issues and scheduling unpredictability.
  3. Compliance & security posture

    • Cloud Guard continuously flags these, which affects audit/compliance signals even though the resource is Oracle-managed.

Expected Behavior

OKE managed add-ons, especially ingress controllers, should:

  • Include sensible default liveness & readiness probes
  • Define CPU and memory requests/limits aligned with best practices
  • Avoid triggering default Cloud Guard container security rules

Additional Context

These findings have been present for months and persist across detections, suggesting they are from the default managed deployment rather than user customization.

Happy to provide more details if needed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions