feat: Bootstrapping admin password and API key, and API commands #16

2026-04-14T13:41:36Z

dannygroenewegen commented

2026-04-14 13:41:36 +00:00

I want to deploy Rauthy with Alakazam and automatically set up SSO integrations. This PR adds the following to support this:

Added bootstrapping admin password and API key
Added abra.sh functions for creating clients, groups and roles with the Rauthy API
Documentation and example for Nextcloud integration

I have deployed and tested my changes
I have updated relevant versions in abra.sh
I have made my environment variable changes backwards compatible
I have added a release note entry

I want to deploy Rauthy with Alakazam and automatically set up SSO integrations. This PR adds the following to support this: - Added bootstrapping admin password and API key - Added abra.sh functions for creating clients, groups and roles with the Rauthy API - Documentation and example for Nextcloud integration * [x] I have deployed and tested my changes * [x] I have [updated relevant versions in `abra.sh`](https://docs.coopcloud.tech/maintainers/upgrade/#updating-versions-in-the-abrash) * [x] I have made my environment variable changes [backwards compatible](https://docs.coopcloud.tech/maintainers/upgrade/#backwards-compatible-environment-variable-changes) * [x] I have added a [release note entry](https://docs.coopcloud.tech/maintainers/upgrade/#creating-new-release-notes)

🚀 1

dannygroenewegen added 1 commit 2026-04-14 13:41:37 +00:00

- Added bootstrapping admin password and API key 5128431f97

- Added abra.sh functions for creating clients, groups and roles with the Rauthy API
- Documentation and example for Nextcloud integration

decentral1se requested review from p4u1 2026-04-16 10:31:29 +00:00

decentral1se removed review request for p4u1 2026-04-16 10:31:59 +00:00

decentral1se reviewed 2026-04-16 10:52:31 +00:00

decentral1se left a comment

Woah, 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!

.env.sample Outdated

						
				@@ -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.

decentral1se commented

2026-04-16 10:40:51 +00:00

We generally have a convention of X_ENABLED=1/0 to 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.

We generally have a convention of `X_ENABLED=1/0` to 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.

dannygroenewegen commented

2026-04-16 15:58:40 +00:00

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?

decentral1se commented

2026-04-16 16:02:45 +00:00

Ah, in my mind the X_ENABLED was per-feature, not per-compose variant 😖

Maybe we can just slowly back away from this and leave it as-is 🙃

Ah, in my mind the `X_ENABLED` was per-feature, not per-compose variant 😖 Maybe we can just slowly back away from this and leave it as-is 🙃

3wordchant commented

2026-04-16 16:43:21 +00:00

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)

Agreed, fine to drop X_ENABLED in general, certainly fine to not do it with this change.

> 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) Agreed, fine to drop `X_ENABLED` in general, certainly fine to not do it with this change.

decentral1se marked this conversation as resolved

.env.sample Outdated

						
				@@ -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="

decentral1se commented

2026-04-16 10:42:12 +00:00

I would do BOOTSTRAP_API_KEY= to drop the example which just needs to be deleted by every operator in the .env who uses it? If you want to include an example of a encoded key, that can be done in the README.md?

I would do `BOOTSTRAP_API_KEY=` to drop the example which just needs to be deleted by every operator in the `.env` who uses it? If you want to include an example of a encoded key, that can be done in the `README.md`?

dannygroenewegen commented

2026-04-16 16:14:54 +00:00

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.

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.

3wordchant commented

2026-04-16 16:45:15 +00:00

@dannygroenewegen I think moving the explanatory comment one line down could help clarify that ewog... is the "read and create rights…" default.

Another option would be to rename this to e.g. API_BASE64_ACCESS_RIGHTS.

This also seems fine; maybe putting a comment that it's set to BOOTSTRAP_API_KEY could help avoid the naming-change confusion?

Fine with whichever solution though really.

@dannygroenewegen I think moving the explanatory comment one line down could help clarify that `ewog...` _is_ the "read and create rights…" default. > Another option would be to rename this to e.g. API_BASE64_ACCESS_RIGHTS. This also seems fine; maybe putting a comment that it's set to `BOOTSTRAP_API_KEY` could help avoid the naming-change confusion? Fine with whichever solution though really.

👍 1

dannygroenewegen commented

2026-04-19 09:33:56 +00:00

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.

👍 1

dannygroenewegen marked this conversation as resolved

abra.sh Outdated

						
				@@ -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() {

decentral1se commented

2026-04-16 10:48:33 +00:00

It's crazy how much work we have to do to work around swarm secrets 🤯

(Feel free to resolve this, just a passing reflection 🙃)

It's crazy how much work we have to do to work around swarm secrets 🤯 (Feel free to resolve this, just a passing reflection 🙃)

decentral1se marked this conversation as resolved

3wordchant commented

2026-04-16 16:46:31 +00:00

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).

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).

👍 1

3wordchant approved these changes 2026-04-16 16:46:39 +00:00

decentral1se approved these changes 2026-04-17 21:50:31 +00:00

dannygroenewegen commented

2026-04-19 09:34:32 +00:00

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!

> 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!

❤️ 1

decentral1se commented

2026-04-20 12:33:23 +00:00

Nice @dannygroenewegen, thanks! I've added you to the team / README.md.

Nice @dannygroenewegen, thanks! I've added you to the team / `README.md`.

dannygroenewegen added 1 commit 2026-05-14 12:36:01 +00:00

merge upstream fa830270e5

dannygroenewegen force-pushed automation from fa830270e5 to 8f29d3baaf

2026-05-14 12:39:15 +00:00

Compare

dannygroenewegen force-pushed automation from 8f29d3baaf to 38067eafc2

2026-05-14 14:14:46 +00:00

Compare

dannygroenewegen merged commit bf053630f3 into main

2026-05-14 14:18:50 +00:00

dannygroenewegen deleted branch automation

2026-05-14 14:18:50 +00:00

dannygroenewegen referenced this issue from a commit

2026-05-14 14:18:52 +00:00

Merge pull request 'feat: Bootstrapping admin password and API key, and API commands' (#16) from eCommons/rauthy:automation into main

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/rauthy#16

Allow edits from maintainers