Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated pkiBundle generation #414

Closed
phozzy opened this issue Dec 12, 2024 · 4 comments
Closed

Automated pkiBundle generation #414

phozzy opened this issue Dec 12, 2024 · 4 comments

Comments

@phozzy
Copy link

phozzy commented Dec 12, 2024

Hello!
Is it possible to have such a flag, so the system will generate pkiBundle if that does not exist already?

Backstory:
I'm trying to automate the provisioning of NixOS using nixos-anywhere and I provide secrets using sops-nix. And this what I'm getting as a result:

[root@testlanzaboote:~]# ll /run/secrets/
total 40
-r-------- 1 root root   36 Dec 12 12:58 etc_secureboot_GUID
-r-------- 1 root root 3272 Dec 12 12:58 etc_secureboot_keys_db_db.key
-r-------- 1 root root 1785 Dec 12 12:58 etc_secureboot_keys_db_db.pem
-r-------- 1 root root 3272 Dec 12 12:58 etc_secureboot_keys_dbx_dbx.key
-r-------- 1 root root 1818 Dec 12 12:58 etc_secureboot_keys_dbx_dbx.pem
-r-------- 1 root root 3272 Dec 12 12:58 etc_secureboot_keys_KEK_KEK.key
-r-------- 1 root root 1805 Dec 12 12:58 etc_secureboot_keys_KEK_KEK.pem
-r-------- 1 root root 3272 Dec 12 12:58 etc_secureboot_keys_PK_PK.key
-r-------- 1 root root 1785 Dec 12 12:58 etc_secureboot_keys_PK_PK.pem
-r-------- 1 root root  108 Dec 12 12:58 token

[root@testlanzaboote:~]# nix run nixpkgs#tree /etc/secureboot/
/etc/secureboot/
├── GUID -> /run/secrets/etc_secureboot_GUID
└── keys
    ├── db
    │   ├── db.key -> /run/secrets/etc_secureboot_keys_db_db.key
    │   └── db.pem -> /run/secrets/etc_secureboot_keys_db_db.pem
    ├── dbx
    │   ├── dbx.key -> /run/secrets/etc_secureboot_keys_dbx_dbx.key
    │   └── dbx.pem -> /run/secrets/etc_secureboot_keys_dbx_dbx.pem
    ├── KEK
    │   ├── KEK.key -> /run/secrets/etc_secureboot_keys_KEK_KEK.key
    │   └── KEK.pem -> /run/secrets/etc_secureboot_keys_KEK_KEK.pem
    └── PK
        ├── PK.key -> /run/secrets/etc_secureboot_keys_PK_PK.key
        └── PK.pem -> /run/secrets/etc_secureboot_keys_PK_PK.pem

6 directories, 9 files

[root@testlanzaboote:~]# nix run nixpkgs#sbctl status
old configuration detected. Please use `sbctl setup --migrate`
system is not booted with UEFI

[root@testlanzaboote:~]# nix run nixpkgs#sbctl setup -- --migrate
old configuration detected. Please use `sbctl setup --migrate`
Moving files...✗
sbctl requires root to run: open /etc/secureboot/keys/KEK/KEK.key: permission denied
@RaitoBezarius
Copy link
Member

Why not run sbctl create-keys in the PKI bundle in your own code?

@phozzy
Copy link
Author

phozzy commented Dec 12, 2024

I'm not yet that proficient with Nix. So, I'm using nixos-anywhere to provision vm's to do destructive experiments.
I've tried to add this option to my code, but probably I lack some knowledge. Here is the current state of my expriments https://codeberg.org/phozzy/kubeadmhomelab/src/commit/f5a5ddae6296f51a0654da050802d3fed16c4054/flake.nix#L44 . Probably, it should be possible to do as you recommend. But I think it would be a nice option to do it natively.
If you think that this is a bad idea, I would easily agree

@RaitoBezarius
Copy link
Member

The problem of a native option is it's policy and there's too many policy to accommodate everyone's needs. Lanzaboote can provide various hooks and capabilities for everyone to implement their own policies, but it cannot contain a default policy, especially a dangerously insecure one (writing private key material on the target system).

To automatically generate the PKI bundle, you can use the extra files feature of nixos-anywhere as mentioned in https://github.com/nix-community/nixos-anywhere/blob/main/docs/howtos/secrets.md.

You generate the PKI bundle in your infrastructure in a secret location and you decide whether to move the public and private key altogether or only the public key information.

Normally, a production deployment would never keep its private key locally and move it (and generate it) in a secure enclave, e.g. a TPM2 or a HSM.

@phozzy
Copy link
Author

phozzy commented Dec 13, 2024

Thanks! Will try that

@phozzy phozzy closed this as completed Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants