How do I know why my health check for Ory Oathkeep...
# ory-selfhosting
b
How do I know why my health check for Ory Oathkeeper is failing? I'm using the k8s helm charts.
Copy code
~ $ oathkeeper health ready --endpoint <http://localhost:4456/>
[GET /health/ready][503] isInstanceReadyServiceUnavailable  &{Errors:map[]}
This is from within the Oathkeeper pod, and the pod logs makes me none the wiser. As with Kratos, the failing health checks are difficult to debug at least for me. I've set the log level to
debug
but although the output is very verbose it's of no help.
r
Hi, did you end up finding a fix for this?
b
No, I had to give up. Spent too many company hours trying to get it to work, unfortunately.
q
I have been running into the same issue. However, if I set demo: true in the helm chart it works. It seems the default config in the helm chart does not work, and it also does not like the empty access-rules.json generated. For instance this config works:
access_rules:
repositories:
- "<https://raw.githubusercontent.com/ory/k8s/master/helm/charts/oathkeeper/demo/access-rules.json>"
authenticators:
anonymous:
enabled: true
jwt:
enabled: false
noop:
enabled: true
unauthorized:
enabled: true
authorizers:
allow:
enabled: true
deny:
enabled: true
mutators:
cookie:
enabled: false
header:
enabled: false
id_token:
enabled: false
noop:
enabled: true
serve:
proxy:
port: 4455
cors:
enabled: true
api:
port: 4456
cors:
enabled: true
prometheus:
port: 9000
However, the default does not:
access_rules:
repositories:
- file:///etc/rules/access-rules.json
serve:
api:
port: 4456
prometheus:
port: 9000
proxy:
port: 4455
Also if I change the repository to
file:///etc/rules/access-rules.json
in the working config it stops working. So this is definitely an issue with the default configuration in the helm chart. I think it wants an authenticators, authorizers, and mutators section defined and a non-empty access-rules file
I have confirmed if you do not have at least one access rule defined and the other config sections mentioned above, the health checks will fail and it will not start. This seems like a bug because ideally you'd want it to run before defining your first access rule, and the configmap by default is incomplete.
b
Thanks Austin, I'll double check and see how the access rules looks inside of my pod!