feat: Bootstrapping admin password and API key, and API commands #16
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/rauthy#16
Reference in New Issue
Block a user
No description provided.
Delete Branch "eCommons/rauthy:automation"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I want to deploy Rauthy with Alakazam and automatically set up SSO integrations. This PR adds the following to support this:
abra.shWoah, amazing work @dannygroenewegen 👏 I have some extremely minor comments but otherwise, this is looking pretty great. Do whatever you want with those comments. There are quite some gymnastics to get this up and running but it seems relatively straightforward, all said and done. I won't have time to test this but I think you should become a recipe maintainer just for this new functionality 😛 Let us know when you're happy with it and we can see about merging/releasing. Let's see what @3wordchant thinks of it. Thanks again!
@ -31,0 +35,4 @@#SECRET_ADMIN_PWHASH_VERSION=v1 # generate=false# API key# When set before first deploy, rauthy will bootstrap an API key with the Base64 encoded JSON access rights.We generally have a convention of
X_ENABLED=1/0to turn stuff on/off. See other recipes for how that is handled. It is a more explicit way of configuring the recipe which I appreciate. Up to you if you want to go that route.I've seen that, but it's not applied everywhere. I feel that's a bit redundant with uncommenting compose.x.yml (also because uncommenting .yml and setting X_ENABLED=0 doesn't always fully disable in every implementation), but no strong preference. It makes sense to at least be consistent within a recipe and compose.smtp.yml in this recipe also uses it. So I add an X_ENABLED env for every compose.x.yml, right?
Ah, in my mind the
X_ENABLEDwas per-feature, not per-compose variant 😖Maybe we can just slowly back away from this and leave it as-is 🙃
Agreed, fine to drop
X_ENABLEDin general, certainly fine to not do it with this change.@ -31,0 +39,4 @@# Default value is read and create rights on Clients, Roles and Groups. See https://sebadob.github.io/rauthy/config/bootstrap.html#api-key# After first deploy, api_secret is also used be abra.sh functions (create_clients, create_groups)#COMPOSE_FILE="$COMPOSE_FILE:compose.api.yml"#BOOTSTRAP_API_KEY="ewogICJuYW1lIjoiYm9vdHN0cmFwIiwKICAiZXhwIjpudWxsLAogICJhY2Nlc3MiOlt7CiAgICAgICJncm91cCI6IkNsaWVudHMiLAogICAgICAiYWNjZXNzX3JpZ2h0cyI6WyJyZWFkIiwiY3JlYXRlIl0KICAgIH0sewogICAgICAiZ3JvdXAiOiJSb2xlcyIsCiAgICAgICJhY2Nlc3NfcmlnaHRzIjpbInJlYWQiLCJjcmVhdGUiXQogICAgfSx7CiAgICAgICJncm91cCI6ICJHcm91cHMiLAogICAgICAiYWNjZXNzX3JpZ2h0cyI6WyJyZWFkIiwiY3JlYXRlIl0KICAgIH0sewogICAgICAiZ3JvdXAiOiAiU2VjcmV0cyIsCiAgICAgICJhY2Nlc3NfcmlnaHRzIjpbInJlYWQiXQogICAgfQogIF0KfQo="I would do
BOOTSTRAP_API_KEY=to drop the example which just needs to be deleted by every operator in the.envwho uses it? If you want to include an example of a encoded key, that can be done in theREADME.md?I used the same naming as Rauthy internally uses and API_KEY is a bit confusing since it's not really a key. From your comment, I'm not sure if you might also be assuming it's a secret, so ignore the following if you got that part: The value in API_KEY is a Base64 encoded JSON with the access rights that should be given to the API key that will be bootstrapped.
The value I put here is Base64 of api.key.example.json, which is read and create rights for clients, groups and roles. Basically, the minimal access rights you need for using the provided abra.sh functions. I feel that's a fair value to put as default? But also happy to put it in the readme if it's confusing to have something here that looks like a secret?
Another option would be to rename this to e.g. API_BASE64_ACCESS_RIGHTS. Maybe that avoids the confusion of thinking it's a default key? Then it's named differently from Rauthy's own naming, but if you get to that layer, you can probably unconfuse yourself with the docs.
@dannygroenewegen I think moving the explanatory comment one line down could help clarify that
ewog...is the "read and create rights…" default.This also seems fine; maybe putting a comment that it's set to
BOOTSTRAP_API_KEYcould help avoid the naming-change confusion?Fine with whichever solution though really.
Good ideas. I will move the comment and rename the env. And want to test again afterwards, might take one or two weeks because of holidays.
@ -14,0 +35,4 @@# Reads a Docker Swarm secret value from the running container# Requires jq locally and SSH access to the server.# Usage: get_secret <secret_name>get_secret() {It's crazy how much work we have to do to work around swarm secrets 🤯
(Feel free to resolve this, just a passing reflection 🙃)
Looks wonderful, if it's working for you then I say shipshipship.
Also echoing the invitation to join as a maintainer @dannygroenewegen (especially to help test that this functionality doesn't break with updates).
I can join as a maintainer!
Nice @dannygroenewegen, thanks! I've added you to the team /
README.md.fa830270e5to8f29d3baaf8f29d3baafto38067eafc2