Open sabinayakc opened 1 year ago
Hello there, This behaviour is due to the k8s readiness probe failing and restarting the pod. The probe is failing because no rules are present in the system, that is why the demo mode works, as it deploys sample data. As Oathkeeper is not k8s native, it expects the rules to be present on start, and treats an an empty rule array as an error state.
How can I instantiate it with a basic rule? Do I have to provide it a basic rule via Helm Values always?
The default helm has the following access rule which might be blank.
config:
access_rules:
repositories:
- file:///etc/rules/access-rules.json
I also created a rule using the CRD to see if it picks it up.
apiVersion: oathkeeper.ory.sh/v1alpha1
kind: Rule
metadata:
name: test-rule
namespace: default
spec:
match:
url: http://http-bin.example/echo
methods:
- GET
authenticators:
- handler: anonymous
authorizer:
handler: allow
mutators:
- handler: noop
To clear up some confusion :)
I see your version is 0.40.2
try to downgrade in 0.40.1
Closing as this is an user error, please reopen if you need more guidance :)
I think the bug is not fixed in the actual version (0.40.6)
👋 @Demonsthere
This is a problem created by PR https://github.com/ory/oathkeeper/pull/1061 and so Release v0.40.2, we should have a flag or option to enable the check performed on PR 1061.
@zepatrik @hperl In our case, if we use Oathkeeper Maester, we get a 503 error when launching Oathkeeper Readiness Probe because there are no rules, although we create them later from the controller.
👋 @Demonsthere can you please reopen the issue ?
I see, so this is a upstream issue from oathkeeper itself 🤔 I will talk with the devs, maybe adding a --allow-empty-rules
flag could be added to disable that check, which would be the default option for maester enabled charts
Would be fine by me.
Is there any progress on this issue?
This issue is unrelated to rules, the pod starts fine with no rules.
Please disregard, I was checking /health/alive instead of /health/ready
Any news on this issue ? I'm facing the exact same challenge, and it's quite frustrating.
If i put a dummy access rule via file, then use the CRD for more control, will there be any issues ?
yes, using a dummy placeholder rule is a valid workaround, as it's a design in oathkeeper that it should start with the access rules supplied. We need to open a issue in oathkeeper to allow for such situation
Preflight checklist
Describe the bug
Installed helm chart using
helm install oathkeeper ory/oathkeeper
.oathkeeper pod has an error with 503 code.
Reproducing the bug
helm install oathkeeper ory/oathkeeper
Relevant log output
Relevant configuration
Version
Helm Version: 0.31.0
On which operating system are you observing this issue?
Linux
In which environment are you deploying?
Kubernetes with Helm
Additional Context
demo: true
it works