docs(proposals): add proposal for the ACL API #743
Conversation
| still maintain this behavior with a switch in the configuration stating that we | ||
| want to load the ACL's from a configured file if it exists. Also it's still | ||
| possible to apply configuration as code like terraform is doing with static | ||
| configuration loaded to destination with the API. |
There was a problem hiding this comment.
I am trying to think if we could have something like "if nothing in the DB, then load from file", but that might be confusing to users as they might think they are updating it by updating on disk and restarting.
If we were to do a behaviour which is based on "keeping" the old behaviour, then I think it should use the API under the hood so we dont have to maintain too much duplicate code.
I would not be too oppose to removing the file behaviour, we just need to tell people a couple of versions in advance and write specific docs on how to load it now. That said, as an advocate for "config as code" and immutability, I do like the current setup where you do it in files.
There was a problem hiding this comment.
Can we keep the file as the actual storage for the ACLs, rather than in the DB?
Even if consumed by the API, users would still have a good old file to do changes too.
There was a problem hiding this comment.
In this part I meant that the switch in the configuration is meant to overwrite the ACL's each time we reboot or reload the configuration. This is meant to keep the current behavior as using the file as a source of truth. This flag could even forbid changes to the rules stored in the database. I think it's interesting because not everyone wants to be use an API to manage the ACL's (I don't think you are the only one @kradalby 😄).
@juanfont I don't think that we can keep the actual storage for the ACL's. As an example for Headscale instances running in Kubernetes, it would require to much logic specific to Kubernetes to update the ConfigMap associated.
There was a problem hiding this comment.
I think that we must add an option to chose between the config file and the database as, even if there's not an official support yet, a lot of peoples want to use Headscale with a GUI, and having the ACLs stored in a database will be more suitable for this purpose, but the "old techies" would like to have file, maybe we can add a condition like if there is a file we use the file (and having an API route to know if ACLs are managed in a file), else storing the config in the database.
And maybe having an error on editing the ACLs with the API as writing a file doesn't seam a good practice to me while dealing with an API.
What do you think ?
docs/proposals/002-acls-cli.md
Outdated
|
|
||
| ```console | ||
| headscale acl get --help | ||
| Get will retrieve the ACLs currently loaded in Headscale. Use the `-o json` |
|
@juanfont Can you merge the PL please ? Or close it because I think the PL is not active anymore |
This Pull Request is a proposal for the ACL API that we could add to Headscale in order to improve usability of Headscale.
This is related to some issues:
Also the PR #581 is implementing part of the GET endpoint.