Question regarding commit f5fb442: "remove old blueprints"

[AndreasVerden]

Hi @astro-stan

I wanted to use your repository as the base for my own Authentic configuration, changing things here and there but keeping track of your work as my "upstream".

Recently you have decided to delete the "old" config and consolidate it into a single file "bootstrap.yaml".

Was there any technical reason to do so?

Since it is hard for me to track the specific changes made I can also not really compare the two variants.

Cool project and thanks in advance :)

[astro-stan]

Hi there,

Thank you for your interest.

Recently you have decided to delete the "old" config and consolidate it into a single file "bootstrap.yaml".

Was there any technical reason to do so?

I created the initial blueprints a few years ago, but quickly realised they were not flexible enough for what I wanted to do, so I abandoned the repo and did not even add a README, as I thought no one would care to use them. A few months ago, I decided to revisit this, hoping the situation had improved.

I pushed a few commits to update the blueprints to work with the newest authentik versions; however, I quickly realised there were 2 big issues with my initial approach:

1. They were too spread out, which created unnecessary complexity
2. It was possible for some blueprints to be applied, while others failed, resulting in partial "bootstrapping" of the authentik instance. In the best case, this would create a broken configuration, and in the worst, probably a vulnerable instance.

To fix both issues, I decided to rewrite the blueprints completely and combine them into a single blueprint. Because authentik applies every blueprint as a single DB transaction, the bootstrap.yaml application is "all or nothing", thus resulting in either a complete bootstrap or no changes at all.

On top of that, in the new bootstrap.yaml I have added an ability to uninstall the blueprint easily, and I have namespaced all objects it creates, so that it can potentially be applied multiple times for different authentik brands. However, (if memory serves) I have not migrated:

• Any of the 2FA stages/flows, as I currently do not use them, and also have no time to test them
• Most of the notification transports/rules (due to how tedious it is to do currently)

All that being said, I have noticed that this repository has gained quite a few stars and even a few forks while I was gone, so I have kept the old blueprints in a branch.

The bigger picture

I have bigger plans for this repo, such as:

• Addition of blueprints for configuring applications, providers, outposts, etc
• Proper versioning (probably tracking the authentik versions)
• E2E testing against an authentik instance
• Distribution via an OCI registry

Unfortunately, authentik's blueprints are still not flexible enough to achieve everything I want to do, so I decided to "keep quiet" for now, while I am opening issues and PRs in authentik to fix some of the issues/limitations I have found.

Issues:

• Add ability to instantiatate blueprints via metamodels goauthentik/authentik#18174
• Allow providing context to blueprints when using metaapplyblueprint goauthentik/authentik#18161
• Blueprints fail to delete stage when it references another stage using !KeyOf goauthentik/authentik#20309
• Cannot configure authentik_events.notificationrule transports via blueprint goauthentik/authentik#20449
• Better management of MFA stages and flows goauthentik/authentik#4380
• Cannot use email stages in user-settings-change flows goauthentik/authentik#20455
• Deleting non-existent flow stage bindings via blueprints fails goauthentik/authentik#20456

PRs:

• blueprints: Add support for generating flat and unique sequences in blueprint enumeration tags goauthentik/authentik#20785
• blueprints: Fix tags not being resolved when used for !Env's default value goauthentik/authentik#20610
• blueprints: Add support for nested !Context values goauthentik/authentik#20577
• blueprints: Add support for dynamic blueprint entries goauthentik/authentik#20490
• blueprints Add EQ and NEQ modes to the !Condition tag goauthentik/authentik#20315

(There could be more which I am forgetting, feel free to take a look at the TODOs in bootstrap.yaml or search the authentik repo)

[AndreasVerden]

Wow, you're busy 👍

1. They were too spread out, which created unnecessary complexity

Not sure what you are referring to. I personally much preferred it in folders, it's what drew me to your repository in the first place. Maybe some of the files could have been merged selectively. But anyway, it's your project and you do you :)

2. It was possible for some blueprints to be applied, while others failed, resulting in partial "bootstrapping" of the authentik instance. In the best case, this would create a broken configuration, and in the worst, probably a vulnerable instance.

I see, the transaction thing is kind of a big deal. Quite unfortunate that it just fails silently, rather unexpected actually.

Makes me wonder, maybe we want to "compile" the blueprints into one file for deployment until authentik fixes that. This could be done as part of the OCI publishing pipeline.

Addition of blueprints for configuring applications, providers, outposts, etc

We have the same plans 😃
We would have used your configuration as the basis and add our own patches on top. Thus it was important to us to be able to easily rebase on your latest version. Not sure how compatible that idea is with your future plans though.

An interesting idea -- but probably not very practical as long as everything must be in a single file -- would be to use your OCI image as the base for our OCI image 🤔

Anyway, best of luck with your goals and thank you for the issues and PRs at authentik 👍