Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow the use of unix sockets for URLs #871

Closed
3 of 6 tasks
nlachfr opened this issue Nov 4, 2021 · 2 comments
Closed
3 of 6 tasks

Allow the use of unix sockets for URLs #871

nlachfr opened this issue Nov 4, 2021 · 2 comments
Labels
feat New feature or request.

Comments

@nlachfr
Copy link

nlachfr commented Nov 4, 2021

Preflight checklist

Describe your problem

Currently, it is not possible to use unix sockets for URLs

- id: some-id
  upstream:
    url: http://127.0.0.1:8080/bbb          # Only http(s)://.... is supported
  match:
    url: http://127.0.0.1:4455/<.*>
    methods:
      - GET
      - POST
  authenticators:
    - handler: cookie_session
      config:
        check_session_url: http://127.0.0.1:8081/aaa          # Only http(s)://.... is supported
  authorizer:
    handler: allow
  mutators:
    - handler: noop
  errors:
    - handler: json

Describe your ideal solution

One solution could be to use the unix:// scheme, allowing distinction between tcp and unix connections.

Workarounds or alternatives

I have found this related discussion : Addressing HTTP servers over Unix domain sockets.

Here is an example of what could be used :

- id: some-id
  upstream:
    url: unix:///path/to/unix.sock?path=/bbb
  match:
    url: http://127.0.0.1:4455/<.*>
    methods:
      - GET
      - POST
  authenticators:
    - handler: cookie_session
      config:
        check_session_url: unix:///path/to/another/unix.sock?path=/aaa
  authorizer:
    handler: allow
  mutators:
    - handler: noop
  errors:
    - handler: json

Version

v0.38.16-beta.1

Additional Context

No response

@nlachfr nlachfr added the feat New feature or request. label Nov 4, 2021
@a-manraj-pvotal
Copy link

Protocol definition isn't even well defined in your post reference from the IETF. As the post mentions, URL definition is required for oathkeeper evaluation. Standard headers or cookies don't exist in a socket communication. I would advise to look into https://man7.org/linux/man-pages/man7/unix.7.html SCM_SECURITY instead of trying to use a network authentication service for local only sockets who don't use network based structure.

@kmherrmann
Copy link

Closing as out of scope for Oathkeeper, unless there's a strong use case and community contribution.

@kmherrmann kmherrmann closed this as not planned Won't fix, can't repro, duplicate, stale Feb 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request.
Projects
None yet
Development

No branches or pull requests

3 participants