generated from coulomb/repo-seed
57 lines
5.8 KiB
Markdown
57 lines
5.8 KiB
Markdown
# Decision Log
|
|
|
|
_Auto-generated by the Custodian State Hub._
|
|
|
|
## D1 — Vault backend: KeePassXC vs HashiCorp Vault in-cluster
|
|
|
|
**Date:** 2026-03-01
|
|
**Decided by:** Tegwick
|
|
|
|
We will follow the suggested path with the following intent: The build up of the security infrastructure needs to be secure from scratch by design. We thus need to bootstrap secure infrastructure before even getting to the stage where a kubernetes cluster is available. This should enable the setup and operation of dev, test and sandbox systems that are separate from production, too. We will base this on KeePassXC. Secure access to KeePassXC is in the responsibility of the user setting up the pre cluster system and should come with the recommendation of keeping the initial master password in a personal password manager. Once a cluster setup is available the credential management will transition to hashicorp in-cluster.
|
|
|
|
---
|
|
|
|
## D2 — Identity source of truth: Keycloak-internal vs LDAP/AD/Entra
|
|
|
|
**Date:** 2026-03-01
|
|
**Decided by:** Tegwick
|
|
|
|
We will go for a hybrid approach that builds on keycloak internal users and extends to ldap/entra federation where appropriate. Here is some background information that went into the decision: 1) there is no existing user base we need to respect at this point in time. 2) there will be the need to integrate ldap/entra users but this is enterprise customer functionality and it will be some time before we offer enterprise plans. this type of integration might well be one of the main drivers for enterprises to purchase an enterprise account when using the hosted turnkey solution. 3) As an extension we also need to consider the bootstrapping usecase: before a ha keycloak infrastructure for user managment is available and for systems that will not connect to it (dev, test, sandbox, ...) some minimal user management without keycloak should be available for ease of use and lightweight spin up of instances. In this case let's come up with a very simplistic single plus test users infrastructure where users are represented as files in a secure subdirectory of the home directory of the user with presets for the user from its linux user settings plus an email adress and automatically generate 2 (optionally more) test users from this base user by adding "N" and "+testN" suffixes to the username and email adress. For me for example the default woule be to have username=tegwick, fullname="Bernd Worsch", email="bernd.worsch@gmail.com" and generate the testusers "tegwick1, Bernd Worsch+test1, bernd.worsch+test1@gmail.com" and "tegwick2, Bernd Worsch+test2, bernd.worsch+test2@gmail.com". I think this plays nicely with the gmail convention of forwarding "+xxx" emails to their main email box. 4) Generated test users should not spill over into other systems. For the users generated from the local user it might be helpful to have a mapping towards a specific user in the production environment and allow for mechanisms to transfer entities from isolated systems to production based on this mapping. So that something owned by the user in a sandboxed infrastructure can be transfered to production with correct mapping of the owning user.
|
|
As user management is a complicated topic at the foundation of the infrastructure this decision should be challenged and if necessary be followed up with a clarification or other decisions for clarificatoin.
|
|
|
|
---
|
|
|
|
## D3 — GitOps tooling: ArgoCD vs Flux vs plain Helm
|
|
|
|
**Date:** 2026-03-01
|
|
**Decided by:** Tegwick
|
|
|
|
Net-Kingdom and Railiance both should be optimized for ai-first development. As best-practices for ai-first are not established and will probably evolve rapidly we will start from the following interpretation for ai-first:
|
|
1) implement in a tdd api-first headless infrastructure approach, testing needs to ensure data integrity of entities
|
|
2) include efficient access to help/manual/description information as a part of the api interface
|
|
3) build mcp layer on top of the headless approach
|
|
4) provide comprehensive commandline tooling where usecases demand it
|
|
5) ui is low priority and can be prototypical to keep overhead and complications low while allowing for quick dev/user interaction feedback loops. professional production grade user interfaces will as a rule be out of scope for a repository but become a repository in their own right, that is targeted to providing and evolving a user interface specifically.
|
|
For this decision it follows that plain helm is fine for starting projects up to keep them lightweight as long as this is helpful and then upgrade/integrate to flux.
|
|
|
|
---
|
|
|
|
## D4 — Secret injection strategy: External Secrets Operator vs Vault Agent Injector
|
|
|
|
**Date:** 2026-03-01
|
|
**Decided by:** Tegwick
|
|
|
|
We go forward using ESO keeping track of possible downsides for later review if they show themselves as relevant.
|
|
|
|
---
|
|
|
|
## D5 — File-based bootstrap user store: separate repo vs in-workplan task vs defer
|
|
|
|
**Date:** 2026-03-01
|
|
**Decided by:** Tegwick
|
|
|
|
We will go with implementing this as local-identity but not separate it into a repo on its own for now.
|
|
Create a documentation file LocalIdentity.md that explaines this as a capability of the net-kingdom bootstrapping infrastructure and explain the upside. Establish clear boundaries for what should be achieved and adress the risks by providding propper out of scope limitations. Then create a separate workplan to implement this in stages with proper documentation. The workplan should include making sure that the local-identity is properly secured by filesystem rights a later stage functionality. The plan should also provide guidance about how to provide minimal OIDC by rebuilding it natively to avoid dependencies according to the goal of easily bootstrapping without heavy dependencies. Finally reference the new workplan from the original workplan and register dependencies explicitly if necessary.
|
|
|
|
---
|