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.

Sign up for GitHub

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

Jump to bottom

More flexible server.address configuration (file descriptor, PROXY...) #5971

Open
2 tasks done
oliverpool opened this issue Sep 7, 2023 · 1 comment · May be fixed by #5973
Open
2 tasks done

More flexible server.address configuration (file descriptor, PROXY...) #5971

oliverpool opened this issue Sep 7, 2023 · 1 comment · May be fixed by #5973
Labels
priority/4/normal Normal priority items status/needs-design Requires thoughtful design type/feature Request for adding a new feature

Comments

@oliverpool
Copy link

Description

First of all, thank you for this nice project!

I would like to deploy authelia using systemd sockets (systemd opens the privileged port and handles it to authelia).
Looking at the code, it seems that server.address currently supports tcp(4|6) and unix (with ?umask).

It would be nice if listening to file descriptor was possible.

Use Case

Better integration with systemd (so that the authelia service does not need to bind on any socket).

Details

Instead of reinventing the wheel, maybe something like https://github.com/AGWA/go-listener/ could be used. It allows to create a net.Listener by parsing a string. For instance:

tcp:80  // all interfaces, port 80
tcp:0.0.0.0:80 // all ipv4, port 80
tcp:[::1]:80 // all ipv6, port 80

unix:/path/to/socket // unix socket (umask is not supported yet, maybe upstream would accept a PR)

fd:4 // listen on file descriptor 4 - which can be passed by systemd

Those listeners can also be wrapped, by prepending them. For instance the tls subpackage allows:

tls:/folder/with/certificates/:tcp:443 // will get the key and certificate from the folder
tls:/path/to/certificate_file:tcp:443 // will get the key and certificate from the file
tls:example.com:tcp:443 // will use lets encrypt to get the certificate

Another (currently) missing feature of go-listener is client certificates. I could also look into implementing them upstream or in a dedicated package.

Example of the proposed change on the config

Current

server:
  address: tcp://:9091
  tls:
    key: "/folder/with/certificates/key"
    certificate: "folder/with/certificates/certificate"
    client_certificates: ["/folder/with/client/cert"]

Proposed:

server:
  listener: tls:/folder/with/certificates/:tcp:9091
  client_certificates: ["/folder/with/client/cert"]

Other examples:

server:
  listener: tls:example.org:fd:4

Contributing

I would be willing to craft a PR, if you think that this approach sound sensible.

Documentation

No response

Pre-Submission Checklist

  • I agree to follow the Code of Conduct

  • I have checked for related issues and checked the documentation
@oliverpool oliverpool added priority/4/normal Normal priority items status/needs-design Requires thoughtful design type/feature Request for adding a new feature labels Sep 7, 2023
@james-d-elliott
Copy link
Member

james-d-elliott commented Sep 7, 2023 •
edited

I don't think that syntax is very common and it looks fairly unfriendly to users which would likely be a larger support and documentation burden. I also don't think adding another dependency specifically for a very narrow feature is very wise.

In addition several changes to this area have been avoided due to them being a breaking change which would be hard to mitigate. The certificates/key/client_certificates configuration is one of those. Our goal is uniformity with all of the listeners and dialers (and various other things like configuring certificates and keys) as closely as possible so the burden for users is low. We also want to preserve the secrets functionality while still making the overall configuration experience better for users.

Instead we could just add support for fd's. When parsing a string like that with url.Parse I believe the Scheme will be fd and the Opaque will be 4. We can just validate this particular use case in Authelia for listener types and make the appropriate changes. Looking at net.FileListener this should be relatively easy (we just have to account for closing it). We'd just need some supporting documentation about how this is configured in systemd.

@oliverpool oliverpool linked a pull request Sep 7, 2023 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
priority/4/normal Normal priority items status/needs-design Requires thoughtful design type/feature Request for adding a new feature
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: listen on file descriptor oliverpool/authelia
2 participants
@oliverpool @james-d-elliott