Admin API authentication

[Sytten]

Preflight checklist

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

Describe your problem

Currently the admin for the open source kratos is not authenticated. This is a bad practice even if the API is only available in a private network, because it's an escalation path for an SSRF. We see that a lot with the metadata API of cloud providers. Thus the open source solution should provide ways to authenticate the admin API.

Describe your ideal solution

What I suggest to start would be to allow static secrets similar to the list currently used for encryption. That should be simple/fast to implement and get the ball rolling. More complex use-cases can use a sidecar.

Workarounds or alternatives

You can always run a side-car that deals with authentication, but this complexifies the setup for simpler use-cases.

Version

0.10.1

Additional Context

No response

[aeneasr]

Thank you @Sytten for this suggestion. I agree that it is not good practice to expose endpoints in the internal network unsecured. However, adding auth to the admin port is out of scope for Ory projects. There are too many options to implement secure API access control, and all have their up and down sides. Basic Auth for example does not support PKI and is not following best practices within advanced infrastructures (e.g. Kubernetes).

For many of these reasons we decided to keep admin API auth out of scope for this project and let implementors choose how they want to secure access. To make this easy, we have exposed the admin endpoint under a dedicated port, as well as a dedicated path prefix (/admin).

[Sytten]

That I can understand, but by that same logic the webhook would not be authenticated either as they don't support PKI.

That being said, this issue should be to rewritten to something along the lines of writing documentation for production deployment that includes a section on the admin api. It could suggest a few basic nginx, caddy, etc configurations that are secure and easy to deploy for a simpler setup.

[aeneasr]

Absolutely, that makes sense! We definitely need some documentation around it :) We can also include some guide using Ory Oathkeeper for example.

[samwinslow]

Hello @Sytten, fancy seeing you here 😄 I wondered if you were eventually able to connect to the admin APIs.

So far, I've tried getting into the Kratos pod with kubectl exec -it <podname> -- sh then using wget to get any response from the Admin APIs, even the health check endpoint, but that doesn't work.

• kubectl exec doesn't authenticate me as the ory user, but rather an unknown user with uid:100. That means no read/write access to temp files and therefore wget fails internally with Permission denied.
• Is there a different/better way to send an HTTP request within the private network (AWS, if that matters)?

Any advice is appreciated.

If we stay with self-hosted we'll set up ngrok at some point, especially if there were guidance about this in the docs, but for now... totally fine to dump JSON to a terminal. I'm being stumped by k8s itself it seems.

[Sytten]

Easiest would be to either deploy a sidecar container that has more permissions or bind the admin port so its accessible at least internally in the cluster. You will probably want a sidecar anyway since the admin endpoint is not protected.

Are you guys dead set on using kratos? You can ping me if you want to chat we have been running it for a few months now and I have opinions.

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️