Structuur in relatie tot afnemende partijen

rutger.putter commented

2026-06-18 07:53:10 +00:00

Collaborator

As @bram.buijs correctly points out in #6, there are things within DAWO that are mandatory on every device and others that are opt-in.

Therefore, I propose converting the core of DAWO into a Nix Flake similar to https://github.com/thecloudexplorers/nixos-blocks.

DAWO would then serve as an input for workspaces used by organizations such as BZK, Municipalities, or UWV; it would contain all mandatory requirements while providing the space to deviate from default options where needed. This allows DAWO to handle about 80% of the heavy lifting (de-burdening), while individual organizations can still utilize their own branding, (user) profiles, and application sets.

Visually, I see it as follows:

flowchart TD
    D[DAWO NixOS Blocks]
    
    U[DAWO UWV]
    V[VNG NixOS Blocks]
    G[DAWO Gemeente X]
    M[DAWO Ministerie Y]

    D -->|input| U
    D -->|input| M
    V -->|input| G
    D -->|input| G

As @bram.buijs correctly points out in #6, there are things within DAWO that are mandatory on every device and others that are opt-in. Therefore, I propose converting the core of DAWO into a Nix Flake similar to https://github.com/thecloudexplorers/nixos-blocks. DAWO would then serve as an input for workspaces used by organizations such as BZK, Municipalities, or UWV; it would contain all mandatory requirements while providing the space to deviate from default options where needed. This allows DAWO to handle about 80% of the heavy lifting (de-burdening), while individual organizations can still utilize their own branding, (user) profiles, and application sets. Visually, I see it as follows: ```mermaid flowchart TD D[DAWO NixOS Blocks] U[DAWO UWV] V[VNG NixOS Blocks] G[DAWO Gemeente X] M[DAWO Ministerie Y] D -->|input| U D -->|input| M V -->|input| G D -->|input| G ```

rutger.putter referenced this issue

2026-06-18 07:53:41 +00:00

Add BIO/NCSC hardening as opt-in modules (nothing auto-enabled) #6

rutger.putter added the

Kind/Discussion

label

2026-06-18 07:55:05 +00:00

rutger.putter self-assigned this

2026-06-18 07:56:26 +00:00

bram.buijs commented

2026-06-18 08:04:15 +00:00

Collaborator

Agreed, this is the right model. Making the DAWO core a flake that downstream workplaces consume as an input, with a clear interface to deviate from the defaults, is exactly what lets it carry the obligations centrally while leaving branding, user profiles and app sets to the organisation.

On the mandatory vs opt-in split from #6, I'd frame the blocks in two tiers:

Mandatory core: the BIO/NCSC obligations that have to hold on every device (disk encryption, the baseline sysctl/SSH/audit/time sources, USB control). These default to on; an organisation can configure them but not silently drop them.
Opt-in: things that are risky, deployment-specific or a policy choice (apparmor, the PAM second factors, smartcard, the egress allowlist). Default off, enabled per workplace.

For the interface the nixos-blocks shape fits well: dawo.<block>.enable plus dawo.<block>.options.<...>, with the norm and origin per block documented (the provenance table in #7 already does this for the hardening set). A consumer then reads one OPTIONS-style doc to see what is mandatory, what is tunable, and where deviating is allowed.

Concretely I can rework the hardening set from #6/#7 into this block shape as a first batch, so we have a working example of the mandatory and opt-in tiers to iterate the structure on. Happy to align on naming first (a dawo. prefix, or something else).

Agreed, this is the right model. Making the DAWO core a flake that downstream workplaces consume as an input, with a clear interface to deviate from the defaults, is exactly what lets it carry the obligations centrally while leaving branding, user profiles and app sets to the organisation. On the mandatory vs opt-in split from #6, I'd frame the blocks in two tiers: - Mandatory core: the BIO/NCSC obligations that have to hold on every device (disk encryption, the baseline sysctl/SSH/audit/time sources, USB control). These default to on; an organisation can configure them but not silently drop them. - Opt-in: things that are risky, deployment-specific or a policy choice (apparmor, the PAM second factors, smartcard, the egress allowlist). Default off, enabled per workplace. For the interface the nixos-blocks shape fits well: `dawo.<block>.enable` plus `dawo.<block>.options.<...>`, with the norm and origin per block documented (the provenance table in #7 already does this for the hardening set). A consumer then reads one OPTIONS-style doc to see what is mandatory, what is tunable, and where deviating is allowed. Concretely I can rework the hardening set from #6/#7 into this block shape as a first batch, so we have a working example of the mandatory and opt-in tiers to iterate the structure on. Happy to align on naming first (a `dawo.` prefix, or something else).

rutger.putter commented

2026-06-18 09:05:00 +00:00

Author

Collaborator

@bram.buijs awesome suggestion! If you have the bandwidth: go for it 😄 ✅.

@bram.buijs awesome suggestion! If you have the bandwidth: go for it :smile: ✅.

rutger.putter commented

2026-06-18 09:07:27 +00:00

Author

Collaborator

@Martijn @victor could you create another repo called DAWO-NixOS-BZK? That repo will then only contain the BZK workplace related config and this repo will be upstream block/core.

rutger.putter commented

2026-06-18 09:56:16 +00:00

Author

Collaborator

So for the mandatory blocks I'd suggest declaring options with lib.mkForce
For the suggested defaults we should use lib.mkDefault
And in Nix language style, we should avoid leaving options empty, or specify a build-time warning when an options is undefined.

So for the mandatory blocks I'd suggest declaring options with `lib.mkForce` For the suggested defaults we should use `lib.mkDefault` And in Nix language style, we should avoid leaving options empty, or specify a build-time warning when an options is undefined.

bram.buijs commented

2026-06-18 09:58:54 +00:00

Collaborator

@rutger.putter wrote in #8 (comment):

@Martijn @victor could you create another repo called DAWO-NixOS-BZK? That repo will then only contain the BZK workplace related config and this repo will be upstream block/core.

DAWO-NixOS-VNG would also be handy in that case. There we can work on the municipality specific configs

@rutger.putter wrote in https://code.overheid.nl/MinBZK/DAWO-NixOS/issues/8#issuecomment-649: > @Martijn @victor could you create another repo called DAWO-NixOS-BZK? That repo will then only contain the BZK workplace related config and this repo will be upstream block/core. DAWO-NixOS-VNG would also be handy in that case. There we can work on the municipality specific configs

👍 1

rutger.putter commented

2026-06-18 10:10:01 +00:00

Author

Collaborator

@bram.buijs wrote in #8 (comment):

@rutger.putter wrote in #8 (comment):

@Martijn @victor could you create another repo called DAWO-NixOS-BZK? That repo will then only contain the BZK workplace related config and this repo will be upstream block/core.

DAWO-NixOS-VNG would also be handy in that case. There we can work on the municipality specific configs

I assume that will also be a shared blocks repo? So let's pick a name that suggests that.
For your work I'd see DAWO-NixOS and DAWO-NixOS-VNG to be inputs for something like DAWO-Gem-Zaanstad.

@bram.buijs wrote in https://code.overheid.nl/MinBZK/DAWO-NixOS/issues/8#issuecomment-662: > @rutger.putter wrote in #8 (comment): > > > @Martijn @victor could you create another repo called DAWO-NixOS-BZK? That repo will then only contain the BZK workplace related config and this repo will be upstream block/core. > > DAWO-NixOS-VNG would also be handy in that case. There we can work on the municipality specific configs I assume that will also be a shared blocks repo? So let's pick a name that suggests that. For your work I'd see `DAWO-NixOS` and `DAWO-NixOS-VNG` to be inputs for something like `DAWO-Gem-Zaanstad`.

rutger.putter referenced this issue

2026-06-18 11:07:52 +00:00

Add BIO/NCSC hardening as opt-in modules (nothing auto-enabled) #6

bram.buijs referenced this issue

2026-06-18 12:04:59 +00:00

WIP: feat(hardening): blocks architecture with core and hardened tiers #16

bram.buijs referenced this issue

2026-06-18 12:12:54 +00:00

GNOME desktop block plus opt-in GNOME hardening #21

bram.buijs referenced this issue

2026-06-18 12:13:30 +00:00

docs(architecture): record key design decisions as ADRs #22