503 Error on Readiness Probe Due to Empty Rules Array in Oathkeeper Helm Chart

[Jorgagu]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

When installing the Oathkeeper Helm Chart using the default configuration, the Oathkeeper pod fails its readiness probe and returns a 503 error. This happens because Oathkeeper expects a non-empty access rules configuration at startup. An empty rules array is treated as an error state, causing the pod to fail even though rules may be added later via CRDs.
Original issue: ory/k8s#595

Discussion

• Empty Rules Issue:
  Oathkeeper is designed to treat an empty rules array as an error state. This behavior causes the readiness probe to fail if no rules are present at startup.

Proposed Solution

Add a flag or configuration option (allow-empty-rules) that permits Oathkeeper to start without any rules, thereby preventing the error. This solution has already been approved by @zepatrik here.

Reproducing the bug

Install the Helm chart:

helm install oathkeeper ory/oathkeeper

Observe the pod logs:
The logs will show errors similar to:

time=2023-04-21T17:39:55Z level=error msg=An error occurred while handling a request ... status_code:503 ...

Or something like this

Screenshot by @sabinayakc in ory/k8s#595

This indicates that the readiness probe is failing because the system could not find any rules.

Note the behavior with demo mode:
When deploying with demo: true, sample rules are provided, and the pod starts without errors.

Version

0.40.2 or later versions

On which operating system are you observing this issue?

Other

In which environment are you deploying?

Kubernetes with Helm

Additional Context

• The issue has been observed starting from version 0.40.2 and appears to persist in later versions introduced by fix: rule readiness check should require at least one rule to be loaded #1061.

• The discussion in the community indicates that while this behavior was initially closed as a user error, further investigation has confirmed it as a valid issue needing an upstream fix.