Gunnar Grop

Trusting CA certificates in Guix System

Sat, 15 Aug 2026 11:43:00 +0200

I’m going to be honest. It took me frankly an embarassing amount of time to figure out how I could trust custom CA certificates in Guix System. I’ve been using it as my main operating system for almost a year at this point, and I only figured this out recently.

The core of my problem was (apart from not being very good at Scheme or Guix) that this wasn’t clearly documented anywhere. Mainstream GNU/Linux distros have a clear way to do this. Just place the PEM encoded files under /usr/local/share/ca-certificates or /etc/pki/trust/anchors, or something similar, then run update-ca-certificates. The certificates will then be added to the system wide trust bundle, usually somewhere under /etc/ssl/certs. Even Nix, which Guix is originally forked from, has a short and very clear article about how to do this.

Guix just has this article: X.509 Certificates. Nowhere does it say how do actually ensure certificates end up in the systems trust bundle. It does mention the nss-certs package, which Guix installs by default to provide CA certs from Mozilla.

Being quite new to Scheme and Guix, I got way to hung up on this package. For some reason I was under the impressions that this package took care of actually generating the trust bundle at /etc/ssl/certs/ca-certificates.crt, which is does not. Turns out, I didn’t need to care about nss-certs at all.

If we look at that file, it should be obvious.

$ ls -la /etc/ssl/certs/ca-certificates.crt
lrwxrwxrwx 1 root root 99  1 jan  1970 /etc/ssl/certs/ca-certificates.crt -> /gnu/store/l3y2wisv02pq1qkh6j101crr8bjs0xzr-ca-certificate-bundle/etc/ssl/certs/ca-certificates.crt

It’s not even part of the nss-certs /gnu/store/ item!

Then I found another package, le-certs, a package for installing root and intermediate CA certs from Let’s Encrypt, and at this point it became quite clear that I’d been an idiot. Turns out, you can just write a package that ensures some certificates files gets placed under /etc/ssl/certs and create the appropriate hash symlinks with c_rehash, then Guix will make sure those certs end up in the system trust bundle.

You can create a package definition anywhere, maybe just in your dotfiles repository, but I opted to create an actual channel since I wanted this package to me installed on both my PC’s, and on my virtual machines (managed via a different central repository).

For reference, here is my Guix channel: https://git.sr.ht/~gunnargrop/guix-channel. And here is the tree output:

.
├── COPYING
├── gunnargrop
│   ├── auxillary
│   │   └── ca-certs
│   │       ├── gunnar-grop-ca.pem
│   │       └── home-internal-ca.pem
│   ├── packages
│   │   └── pki.scm
│   └── services
│       └── virtualization.scm
└── README.md

Here is what (gunnargrop packages pki) looks like:

(define-module (gunnargrop packages pki)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix build-system trivial)
  #:use-module (guix packages)
  #:use-module (guix gexp)
  #:use-module (guix utils)
  #:use-module (gnu packages tls)
  #:use-module (gnu packages perl))

(define-public grop-certs
  (package
   (name "grop-certs")
   (version "1")
   (source #f)
   (build-system trivial-build-system)
   (inputs
    `(("gunnar-grop-root"
       ,(local-file "../auxillary/ca-certs/gunnar-grop-ca.pem"))
      ("home-internal-root"
       ,(local-file "../auxillary/ca-certs/home-internal-ca.pem"))))
   (native-inputs
    (list openssl perl))
   (arguments
    (list
     #:modules '((guix build utils))
     #:builder
     #~(begin
         (use-modules (guix build utils))

         (let ((out (string-append #$output "/etc/ssl/certs"))
               (openssl
                (assoc-ref %build-inputs "openssl"))
               (perl
                (assoc-ref %build-inputs "perl"))
               (gunnar-grop-root (assoc-ref %build-inputs "gunnar-grop-root"))
               (home-internal-root (assoc-ref %build-inputs "home-internal-root")))

           (mkdir-p out)
           (for-each
            (lambda (cert)
              (copy-file cert (string-append out "/"
                                             (strip-store-file-name cert))))
            (list gunnar-grop-root
                  home-internal-root))

           ;; Create hash symlinks suitable for OpenSSL ('SSL_CERT_DIR' and
           ;; similar.)
           (chdir out)
           (invoke (string-append perl "/bin/perl")
                   (string-append openssl "/bin/c_rehash")
                   ".")))))

   (home-page "https://grop.dev")
   (synopsis "Gunnar Grop CA certificates")
   (description
    "This package provides a certificate store containing my own
root and intermediate CA certificates.")
   (license license:public-domain)))

If you look at the le-certs package you can see that mine is basically a straight copy. The main difference being that my inputs (.pem files) come from local files, instead of being downloaded from the internet.

Anyway, after adding my own channel to /.config/guix/channels.scm I just added grop-certs to my systems packages definition:

(use-modules (gunnargrop packages pki))
; ...
(packages (append (list curl
                        grop-certs)
                  %base-packages))

And voilà! After a system reconfigure my CA certificates are present in the system trust bundle, and I can finally use curl without specifying CA files.

I hope whoever reads this finds it helpful, as I know I struggled with this particular part of Guix for a long time.

Fontconfig problems with Nix on Guix System

Mon, 20 Jul 2026 16:49:00 +0200

Since I started using Guix System about a year ago, I’ve absolutely loved it. I can easily say it’s my favourite OS out of any I’ve used, thus far. Although, compared to Nix (which Guix is based on), it has comparatively few software packages packaged for it. This is no wonder when considering the sheer amount of packages for Nix.

Fortunately this “problem” is easily remedied by just using Nix on Guix System! This is made extra easy by using the system service nix-service-type (documentation).

Now I use Nix on Guix System, mostly using Home Manager, and for the most parts it works great. One of the few problems I’ve run into is that graphical programs installed via Nix get the wrong fonts, like they couldn’t find any fonts and always used a fallback. In this case, Iosevka, which I had installed with Guix. No matter which font packages I installed, every application would use Iosevka.

For example, Firefox (installed via Nix) would log this error whenever started:

Fontconfig error: Cannot load default config file: File not found:

Turns out that this is a problem with Fontconfig. Or rather, that Guix and Nix manages their Fontconfig configs differently. Guix System does not set the environment variables FONTCONFIG_FILE or FONTCONFIG_PATH, which are used by Fontconfig to figure out where configurations are placed. By default, Fontconfig looks in the directory /etc/fonts to find fonts and configs, but this is not where Guix places them. Guix instead places font configuration in the active system configuration directory, under /run/current-system/profile.

So, to fix the font problems with Nix applications, all we have to do is to set the following environment variables:

FONTCONFIG_PATH=/run/current-system/profile/etc/fonts
FONTCONFIG_FILE=/run/current-system/profile/etc/fonts/fonts.conf

In my case, I opted to do this in my Guix Home configuration, using the home-bash-service-type service, like so:

(home-environment
 (services
  (append (list (service home-bash-service-type
                         (home-bash-configuration
                          (environment-variables
                           '(("FONTCONFIG_FILE" . "/run/current-system/profile/etc/fonts/fonts.conf")
                             ("FONTCONFIG_PATH" . "/run/current-system/profile/etc/fonts")))))
                )
          %base-home-services)))

But you can set them however you like. After the environment variables are set, applications installed with Nix should find your installed fonts.

Full RSS Feed

Thu, 14 May 2026 15:57:00 +0200

When I started this blog I didn’t know that Hugo just shows the summary of each post in the default posts RSS feed.

That has now been corrected, so if you subscribe to my RSS feed you now see the full posts in your RSS client.

Thank you to Junian for their post “Full-Text RSS in Hugo” that showed me how to do this. Please read their blog post if you’re looking to do this for your own blog.

NixOS WSL on Corporate Networks

Sun, 03 May 2026 20:49:00 +0200

Abstract

Last year I started exclusively using Guix System on my personal computers and fell in love with it. Since then I’ve started to grow a bit “bored” with more traditional GNU/Linux system, and whenever I have to use one I quickly start missing the declarative nature of configuring guix/nix systems.

Until very recently I’ve been stuck using openSUSE Tumbleweed via WSL2 on my work laptop (since I have no option for anything other than Windows). It’s worked well and I still think Tumbleweed is a great distro, but like I said, I was just a bit bored of it.

At first I obviosuly looked into using Guix System on WSL2, which is possible via the “WSL2” image type that guix offers. But, I deemed it a bit of a hassle, mostly because there are no pre-built images available. If you didn’t know, you can see available image types by running:

guix system image --list-image-types

Anyway, around the same time I saw that there are community built WSL2 NixOS images available via the NixOS-WSL project. Not only that, but they also provide WSL-related configuration options for NixOS. So, this was the easier starting point. I think most of my colleagues would be more interested in Nix over Guix, anyhow.

Challanges

The main challanges on my corporate network are these:

A corporate HTTP proxy for all outgoing traffic.
The proxy handles authentication via NTLM.
The proxy serves a TLS certificate signed by an in-house CA.

Installation

The Proxy

First of all, setting HTTP_PROXY and HTTPS_PROXY in Linux, as per usual, doesn’t work very well with NTLM.

To get around this I installed a proxy on the Windows host that handle authentication with the upstream proxy, then I just use that one via HTTP_PROXY and HTTPS_PROXY in Linux.

My proxy of choice is Px, because it’s very easy to setup. We just need to download it and change one line in the config file (px.ini).

[proxy]

; NTLM server(s) to connect through. IP:port, hostname:port
;   Multiple proxies can be specified comma separated. Px will iterate through
;   and use the one that works
server = http://proxy.example.com:8080

...

Then start it with:

.\px.exe

Now Px should be running and is listening on the default host and port.

http://127.0.0.1:3128

Install NixOS

Download the latest release image of NixOS-WSL.
Install the image with:
```
wsl --install --from-file nixos.wsl
```
Start NixOS with:
```
wsl -d NixOS
```

Now that NixOS is started we can finally start configuring it.

We’ll start by (temporarily) telling NixOS to use our proxy (documentation).

# Set HTTP proxy to the Px proxy we installed earlier
proxy_url="http://localhost:3128/"
export http_proxy="$proxy_url"
export HTTP_PROXY="$proxy_url"
export https_proxy="$proxy_url"
export HTTPS_PROXY="$proxy_url"

Before continuing, you’ll need to check if your upstream corporate HTTP proxy serves a custom TLS certificate. This can easily be done by just checking if you get any SSL/TLS issues when requesting a regular website.

curl https://duckduckgo.com

If you get any errors with the previous command, you’ll have to fetch a copy of whatever public CA certificate is used to trust your proxy’s TLS certificate.

From here I’ll assume you have all CA certificates you need in a file called ca.pem.

Now we need to update NixOS.

# Let's temporarily trust our CA certificate
# https://nix.dev/manual/nix/2.28/installation/env-variables.html?highlight=certi#nix_ssl_cert_file
export NIX_SSL_CERT_FILE=/path/to/ca.pem

# Update NixOS
# We'll use 'sudo -E' to preserve the environment variables we just set
sudo -E nix-channel -v --update

Note: If your upstream proxy has any kind of malware scanning (like mine does), the update can potentially take a very long time. For me it took about ~60 minutes.

Configure NixOS

Now it’s time to configure NixOS for real. I’ll provide you with a simple NixOS and home-manager configuration that you can build upon later.

I’ve based these configs on the excellent minimal nix-starter-config provided by Misterio77 on GitHub.

The structure:

.
├── flake.nix              # The "init" file
├── home-manager
│   └── home.nix           # Home configuration
└── nixos
    └── configuration.nix  # System configuration

I’ll assume the hostname is nixos and the user account is nixos, which are both default in NixOS-WSL.

flake.nix:

{
  description = "NixOS config for WSL2";

  inputs = {
    # Nixpkgs
    nixpkgs.url = "github:nixos/nixpkgs/nixos-25.11";

    # NixOS WSL
    nixos-wsl.url = "github:nix-community/NixOS-WSL/main";

    # Home manager
    home-manager.url = "github:nix-community/home-manager/release-25.11";
    home-manager.inputs.nixpkgs.follows = "nixpkgs";
  };

  outputs = {
    self,
      nixpkgs,
      nixos-wsl,
      home-manager,
      ...
  } @ inputs: let
  in {
    # NixOS configuration entrypoint
    # Available through 'nixos-rebuild --flake .#nixos'
    nixosConfigurations = {
      nixos = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        specialArgs = {inherit inputs;};
        modules = [
          ./nixos/configuration.nix
          nixos-wsl.nixosModules.default
          {
            system.stateVersion = "25.11";
            wsl.enable = true;
          }
        ];
      };
    };

    # Standalone home-manager configuration entrypoint
    # Available through 'home-manager --flake .#nixos@nixos'
    homeConfigurations = {
      "nixos@nixos" = home-manager.lib.homeManagerConfiguration {
        # Home-manager requires 'pkgs' instance
        pkgs = nixpkgs.legacyPackages.x86_64-linux; # FIXME replace x86_64-linux with your architecture
        extraSpecialArgs = {inherit inputs;};
        modules = [./home-manager/home.nix];
      };
    };
  };
}

home.nix:

# This is your home-manager configuration file
# Use this to configure your home environment (it replaces ~/.config/nixpkgs/home.nix)
{
  inputs,
  lib,
  config,
  pkgs,
  ...
}: {
  nixpkgs = {
    config = {
      # Disable if you don't want unfree packages
      allowUnfree = true;
    };
  };

  home = {
    username = "nixos";
    homeDirectory = "/home/nixos";
  };

  programs.home-manager.enable = true;

  # https://nixos.wiki/wiki/FAQ/When_do_I_update_stateVersion
  home.stateVersion = "25.11";
}

configuration.nix:

# Edit this configuration file to define what should be installed on
# your system. Help is available in the configuration.nix(5) man page, on
# https://search.nixos.org/options and in the NixOS manual (`nixos-help`).

# NixOS-WSL specific options are documented on the NixOS-WSL repository:
# https://github.com/nix-community/NixOS-WSL

{ config, lib, pkgs, ... }:

{
  wsl.enable = true;
  wsl.defaultUser = "nixos";
  wsl.startMenuLaunchers = true;

  nix.settings.experimental-features = [ "nix-command" "flakes" ];

  # This value determines the NixOS release from which the default
  # settings for stateful data, like file locations and database versions
  # on your system were taken. It's perfectly fine and recommended to leave
  # this value at the release version of the first install of this system.
  # Before changing this value read the documentation for this option
  # (e.g. man configuration.nix or on https://nixos.org/nixos/options.html).
  system.stateVersion = "25.11"; # Did you read the comment?

  networking.proxy.default = "http://127.0.0.1:3128";
  # FIXME replace with your actual no_proxy settings
  networking.proxy.noProxy = "localhost,127.0.0.1,mycompany.com";

  security.pki.certificates = [
    # FIXME replace with your actual company CA certificate
    # The certificate(s) for your corporate proxy
    ''
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    ''
  ];
}

Now that we have the configuration files we can configure evertyhing. I’ll assume your configuration files are in a directory called /home/nixos/.dotfiles, with the exact directory structure I showed above.

# We'll enable experimental nix features (only needs doing once)
export NIX_CONFIG="experimental-features = nix-command flakes"

# Configure the system
sudo -E nixos-rebuild switch --flake /home/nixos/.dotfiles#nixos

# Bootstrap home-manager (only needs doing once)
nix shell nixpkgs#home-manager

# Configure home
home-manager switch --flake /home/nixos/.dotfiles#nixos@nixos

Alright, now it’s all done! Assuming you correctly setup the proxy config and TLS config in configuration.nix, you should now have a working NixOS container in WSL. In the future you can just build upon configuration.nix and home.nix for further configuration. You should also preferably put everything in a version controlled git repository, for safe-keeping.

Conclusion

As you can see, and depending on your companys networking, it’s not just plug-and-play with NixOS for WSL. But, it’s not exactly rocket science either.

I’ve been using NixOS on WSL based on this setup for a while now, and I love using it.

Of course, I would still want to try out Guix System for WSL as well, but it looks like it’s a fair amount of extra work to get it working. Mostly because I’ll have to write a working config (proxy/TLS and all that) and then build an image based on it before I can even install it in WSL. But that will probably be a future blog post. 🙂

Enjoy NixOS!

Argo CD ApplicationSet with templatePatch

Wed, 04 Feb 2026 12:39:00 +0100

Abstract

Deploying applications with Argo CD can be done different ways for several different reasons. For me, it differ quite a bit between the deployments I maintain professionally, versus the stuff I deploy in my homelab. In my homelab I don’t care as much about stability or maintainability, and I care more about testing interesting things, quickly, and easily.

Therefore I’ve been trying to utilize Argo CD’s ApplicationSet resource to deploy applications in my homelab as easily and quickly as possible. Preferably I’d only need a single ApplicationSet to deploy everything. Something i didn’t think possible before I realized that the templatePatch field can be used instead of template for basically everything.

Writing ApplicationSets

Normally, you’d write an ApplicationSet something like this:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: example
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
    - git:
        repoURL: https://git.example.com/argocd
        revision: HEAD
        files:
          - path: "**/values.yaml"
  template:
    metadata:
      name: '{{ .path.basename }}'
    spec:
      project: default
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{ .path.basename }}'
      source:
        chart: example-cahrt
        repoURL: https://example.github.io/charts/
        targetRevision: 1.0.0
        helm:
          valueFiles:
            - '{{ .path.path }}/values.yaml'

In this case the ApplicationSet uses a git generator to look through a specified git repository and generates an Application resource for every file it finds called values.yaml. Furthermore, the name of the generated Applications will be the name of the directory where values.yaml lives.

This ApplicationSet will work great if your’re planning on running several instances/deployments of the same Helm chart! An example git directory structure would look something like this:

.
├── app1
│   └── values.yaml
├── app2
│   └── values.yaml
└── app3
    └── values.yaml

But that’s not quite what I’m after. In my homelab I run many different charts, with different requirements. Effectively, I have three distinct types of deployments:

Helm charts with a values file.
Helm charts with a values file and additional manifests.
Just Kubernetes manifests.

So, with the help of templatePatch I came up with this design:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: meta-applicationset-applications
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
    - git:
        repoURL: https://git.sr.ht/~gunnargrop/argocd-env-mars.internal
        revision: HEAD
        files:
          - path: "apps/**/meta.yaml"
  templatePatch: |
    spec:
      sources:
        {{- if .sources.chart.enabled }}
        - repoURL: "{{ .sources.chart.repoURL }}"
          chart: "{{ .sources.chart.chart }}"
          targetRevision: "{{ .sources.chart.targetRevision }}"
          helm:
            valueFiles:
              - "$values/{{ .path.path }}/values.yaml"
        {{- end }}
        {{- if .sources.values.enabled }}
        - repoURL: https://git.sr.ht/~gunnargrop/argocd-env-mars.internal
          targetRevision: "{{ .sources.values.targetRevision }}"
          ref: values
        {{- end }}
        {{- if .sources.manifests.enabled }}
        - repoURL: https://git.sr.ht/~gunnargrop/argocd-env-mars.internal
          targetRevision: "{{ .sources.manifests.targetRevision }}"
          path: "{{ .path.path }}/manifests"
        {{- end }}
      {{- with .syncPolicy }}
      syncPolicy:
        {{- toYaml . | nindent 6 }}
      {{- end }}
  template:
    metadata:
      name: "{{ .path.basename }}"
    spec:
      project: "{{ .project }}"
      destination:
        server: https://kubernetes.default.svc
        namespace: "{{ .namespace }}"

The biggest difference here is that spec.source and spec.syncPolicy is defined entirely inside of the templatePatch field. What this allows for is much more powerful gotmpl templating, where we can have if statements and other handy constructs.

It might be a bit dense to read and understand from a glance, so I’ll point out how it works by showing you what the git repository structure looks like.

.
└── apps
    ├── app1
    │   ├── meta.yaml
    │   └── values.yaml
    ├── app2
    │   ├── manifests
    │   │   └── secret.yaml
    │   ├── meta.yaml
    │   └── values.yaml
    └── app3
        ├── manifests
        │   ├── deployment.yaml
        │   ├── ingress.yaml
        │   └── service.yaml
        └── meta.yaml

As you can see this ApplicationSet takes care of deploying all of the different deployment types I have in my homelab. Importantly every “app” in the git repo have a special meta.yaml file. This file is just used to specify a bunch of variables that Argo CD will read and use in the Application templating.

Here’s one example of a meta.yaml that just deploys regular manifests:

project: default
namespace: default

sources:
  chart:
    enabled: false

  values:
    enabled: false

  manifests:
    enabled: true
    targetRevision: HEAD

syncPolicy:
  automated:
    prune: true

And here is an example of a meta.yaml that deploys a Helm chart:

project: default
namespace: default

sources:
  chart:
    enabled: true
    repoURL: registry-1.docker.io/example
    chart: example
    targetRevision: 1.0.0

  values:
    enabled: true
    targetRevision: HEAD

  manifests:
    enabled: false

syncPolicy:
  automated:
    prune: true

  syncOptions:
    - CreateNamespace=true

  managedNamespaceMetadata:
    labels:
      trust: enabled

Both of these files will be picked up by the ApplicationSet, which will create one Application per file.

This is pretty much all I want! Now I no longer have to write any Application/ApplicationSet resources manually, since I can just create a simple meta.yaml file in a directory in the specified git repository, and the one ApplicationSet will deploy all of my applications.

Conclusion

As you can see, ApplicationSets are even more flexible than at first glance. Of course, your needs/wants will probably differ from mine. Maybe you want a different directory structure, or to supply several values files to a Helm deployment? Argo CD and it’s ApplicationSets can probably handle it.

Hopefully this little article has provided you a starting point for how to templatePatch.

Publishing Static Sites on sourcehut pages

Wed, 22 Oct 2025 10:16:00 +0200

Abstract

I mentioned in a previous post that I use Kubernetes to deploy my blog. Since my professional work (and my homelab) consists primarily of managing Kubernetes deployments, this didn’t seem like a bad idea. Albeit a bit overkill. But I had all the infrastructure in place, so I went with it.

I’ve also mentioned that I’ve migrated all my personal git repositories over to sourcehut recently, but it wasn’t until yesterday that my brain registered that sourcehut has another component, pages, that allow you to publish static websites… This is way easier!

Not only is it super easy to use, and integrates well with other sourcehut components (git/hg, builds), but every user even gets their own domain, in the form of username.srht.site. It’s also very easy to use your own custom domains! This can be done at your domain registrar, by pointing you DNS records to the following IPv4 (A record) and IPv6 (AAAA record) addresses.

@ IN A 46.23.81.157

@ IN AAAA 2a03:6000:1813:1337::157

Note: These IP addresses might be subject to changes. Please always refer to the official documentation.

Anyhow, I thought I might do a little write-up on how to use sourcehut pages, and just to tell you that I’ve migrated this blog over to it.

Publishing your Site

You’ll only need a few things for this to work.

A sourcehut account.
A sourcehut git repository containing you static site (I’m using Hugo).
A sourcehut build manifest to publish your site.

You can take a log at the source code for this blog, if you want a reference on what such a git repo might look like: https://git.sr.ht/~gunnargrop/grop.dev.

The name of the git repository should preferably be the name of the site. In my case, the repo is called “grop.dev”. In your case it might be called “username.srht.site”.

After you have your git repository, we just have to create a build manifest. This is done by creating a file called .build in the root of the repository. The file will look something like this:

---
image: alpine/latest

oauth: pages.sr.ht/PAGES:RW

packages:
  - hut
  - hugo

environment:
  site: username.srht.site

tasks:
  - package: |
      cd $site
      hugo
      tar -C public -cvz . > ../site.tar.gz

  - upload: |
      hut pages publish -d $site site.tar.gz

And that’s it! After you’ve created this build manifest, whenever you push changes a commit to your repository, this build manifest will trigger and publish your Hugo site to your sourcehut page. Which you can then visit at https://username.srht.site. 🙂

Of note here is that we’re using a tool called hut, a CLI tool to interact with sourcehut. It authenticates to sourcehut using OAuth2 token, which the build system has a handy keyword for. The oauth keyword takes care of generating a token for us, that the CLI tool will use in our build.

# In this case, we generate a token that grants us read/write
# permissions to the sourcehut pages API
oauth: pages.sr.ht/PAGES:RW

But is this CI good enough? I don’t think so, since I don’t want changes to get published every time I push something to my repo. This can be solved by just not triggering the CI when we push something, like so:

git push --push-option skip-ci

That’s what I do normally, to not unnecessarily waste sourcehut resources, but I also added another part to the build manifest, so it just publishes my page when I push a new git tag to the repo.

---
image: alpine/latest

oauth: pages.sr.ht/PAGES:RW

packages:
  - hut
  - hugo

environment:
  site: grop.dev

tasks:
  - setup: |
      # Exit pipeline if NOT triggered by tag
      if [[ "$GIT_REF" != refs/tags/* ]]; then
          complete-build
      fi

  - package: |
      cd $site
      hugo
      tar -C public -cvz . > ../site.tar.gz

  - upload: |
      hut pages publish -d $site site.tar.gz

Conclusion

As you can see, it’s in fact very easy to publish your own static site to sourcehut pages. I would recommend giving it a go if you want an easy place to host you blog, or whatever else!

Building OCI Images with sourcehut builds

Sun, 19 Oct 2025 22:16:00 +0200

Abstract

More and more I find myself needing custom built OCI images, for various purposes. Most recently has been this blog, in fact. Since I’m hosting this blog in Kubernetes, one of the most straight forward ways of keeping it updated and version controlled was to build an OCI image and include the relevant Hugo files in it.

While I’m under no illusions that it’s the best way to deploy a Hugo blog, it is very easily maintained and version controlled. I’ve also quite recently migrated all of my git repositories over to sourcehut, and this combined with my, maybe non-traditional, way of deploying this blog has forced me to have a look as sourcehut’s CI/CD system. Simply called “builds”.

I might do a more in-depth review of sourcehut builds at some point, but for now I thought it might be interesting to share how I’ve gone about building, publishing and signing OCI images using it.

What I’ll be doing in this guide is the following:

Create a sourehut build manifest.
Building a multi-arch OCI image with podman.
Publishing the OCI image to a registry.
Signing the manifest digest using cosign.

If you want to take a look at a real life example, just take a look at the source code for this blog.

Prerequisites

There are a few things you’ll need to follow this guide:

A sourcehut account (of course)
An OCI registry to push images to (Docker Hub, etc)
A sigstore key pair (for signing images)

sigstore key pair

If you do not yet have a sigstore keypair, you can simply create one using cosign.

cosign generate-key-pair

You’ll be prompted for a password, and then the following files will be created in you current directory

cosign.pub (your public key)
cosign.key (your private key)

To sign anything with your private key, you’ll need the password you supplied, of course. And this should go without saying, but NEVER share your private key or password with anyone.

Registry authfile

To effectively, and more safely, handle our OCI registry credentials, we should create an “authfile”.

An authfile looks like this:

{
        "auths": {
                "registry-1.docker.io": {
                        "auth": "dXNlcm5hbWU6cGFzc3dvcmQ="
                }
        }
}

Where a top-level block “auths” contains a dictionary of registry URIs, and each of those registry elements has an “auth” field, containing a base64 encoded representation of the string “username:password”.

You can generate the auth string by just piping your credentials to the base64 command (on UNIX systems):

echo "my-user@example.com:my-secret-password" | base64 --wrap 0

Another handy thing of using an authfile is that every tool we’re going to use in this tutorial can use it. That includes:

podman (or docker, if you want)
cosign
skopeo

For this tutorial I’ll juse assume we’re dealing with Docker Hub, like in the example above.

Creating sourcehut Secrets

Now that we have our sigstore keys and out authfile, we need to create three different secrets in sourcehut, that we’ll use in our pipeline.

If you go to Manage secrets in sourcehut, you’ll have the option to create three types of secrets.

SSH Key
PGP Key
File

We’ll create three secrets of the “File” type.

Secret Name	Secret Content	File Path	File Mode
DOCKER_HUB_AUTHFILE	<your authfile>	~/.auth	600
COSIGN_KEY	<your cosign private key>	~/.cosign.key	600
COSIGN_PASSWORD	<your cosign private key password>	~/.cosign.password	600

When we’re using these secrets in our pipeline later, they will be mounted as files in our build environment, at the specified paths and with the specified file permissions.

Task: Setup

Now that we have our secrets we just need to create a build manifest for sourcehut builds to use. You can do this either by creating a files called “.build.yml” in the root in one of your git repositories. Or you can created a directory called “.builds” and place any “.yml” files in it.

According to the documentation, you can effectively just have up to 4 different build manifests (files) under “.builds”. If you have more than 4, then a random set of 4 builds will be selected when you’re triggering the CI.

For this tutorial though, just one build manifest is plenty. We’ll create a file in our git repository that looks like this. We’ll create a file in our git repository called “.builds/publish.yml”

Now we’ll start actually writing the build manifest. First of all, we’ll use the alpine/latest image to run our CI. But you can choose any of the available images here.

---
image: alpine/latest

Secondly we’ll install some packages in the build environment. Most of them are obvious, but iptables it needed for podman to be able to function correctly, and jq is just a handy tool to have.

packages:
  - iptables
  - podman
  - cosign
  - skopeo
  - jq

Then, we’ll specify which secrets we want to use. This is done by specifying a list of UUIDs, then ones you see when you go to the “Manage secrets” page.

secrets:
  - 06965d05-4554-4832-8a60-628e1a219a39  # DOCKER_HUB_AUTHFILE
  - f3e67338-52fb-4d8d-aa4d-7529bbf74cef  # COSIGN_KEY
  - a99495b8-32a3-4b37-9c9f-7e6772dbfba2  # COSIGN_PASSWORD

Then we’ll specify some environment variables for our build environment. Note that the PROJECT variable is just the full name of the git repository, which is what the directory containing the source code will be called.

environment:
  PROJECT: grop.dev                      # Name of the git repo (will also be the OCI image name)
  OCI_PLATFORM: linux/amd64,linux/arm64  # Platforms to build for
  OCI_REGISTRY: registry-1.docker.io     # Which registry to upload the image to
  OCI_REPOSITORY: gunnargrop             # Which repository to upload the image to

Lastly, we’ll write the tasks list. I usually like to have a setup task to take care of some basic stuff that are needed for the rest of the tasks.

Here you can see that I’ve included a task that exits if it’s not triggered buy a git tag (as opposed to a commit, etc). You can do this however you like, but I like running my builds only when I’m pushing a new tag to the repository. The build system gives us a handy function called “complete-build” that we can call, cleanly exiting the CI.

Note also that when setting environment variables for other tasks to use, we need to write them to the “~/.buildenv” file. This is a special file that is sourced by all tasks.

tasks:
  - setup: |
      # Exit pipeline if NOT triggered by tag
      if [[ "$GIT_REF" != refs/tags/* ]]; then
          complete-build
      fi

      # Set environment variables
      set +x
      cd $PROJECT
      # Let the VERSION variable be the name of the latest git tag
      echo "VERSION=$(git tag --sort=-v:refname | awk '/^\d/' | head -n 1)" >> ~/.buildenv
      set -x

      # Setup for podman, which requires cgroups to function
      sudo rc-update add cgroups
      sudo rc-service cgroups start

Note here that I’ve encapsulated the setting of environment variables by set +x and set -x. This isn’t strictly necessary here, it’s just something I do in every build manifest, in case I want to handle secrets here. And you should always encapsulate your handling of secrets like this, since this prevents the commands to be written to stdout.

set +x
# For example
MY_SECRET_VAR="$(cat ~/.my-secret-password-file)"
set -x

So, here is the full build manifest thus far.

---
image: alpine/latest

packages:
  - iptables  # Needed for podman
  - podman
  - cosign
  - skopeo
  - jq

secrets:
  - 06965d05-4554-4832-8a60-628e1a219a39  # DOCKER_HUB_AUTHFILE
  - f3e67338-52fb-4d8d-aa4d-7529bbf74cef  # COSIGN_KEY
  - a99495b8-32a3-4b37-9c9f-7e6772dbfba2  # COSIGN_PASSWORD

environment:
  PROJECT: grop.dev
  OCI_PLATFORM: linux/amd64,linux/arm64
  OCI_REGISTRY: registry-1.docker.io
  OCI_REPOSITORY: gunnargrop

tasks:
  - setup: |
      # Exit pipeline if NOT triggered by tag
      if [[ "$GIT_REF" != refs/tags/* ]]; then
      complete-build
      fi

      # Set environment variables
      set +x
      cd $PROJECT
      # Let the VERSION variable be the name of the latest git tag
      echo "VERSION=$(git tag --sort=-v:refname | awk '/^\d/' | head -n 1)" >> ~/.buildenv
      set -x

      # Setup for podman, which requires cgroups to function
      sudo rc-update add cgroups
      sudo rc-service cgroups start

Task: Build

Now we need a task to actually build our OCI image. I’d recommend always creating a manifest with podman, instead of just building images. Creating a manifest simplifies building for multiple architectures, as well as making it possible to push every image in the manifest with just one command.

Assuming your Dockerfile is in the root of the repository, we can just cd into the directory and run podman build.

- build_oci: |
    sudo podman manifest create "$PROJECT:$VERSION"

    cd $PROJECT
    sudo podman build \
    --file "Dockerfile" \
    --platform "$OCI_PLATFORM" \
    --manifest "$PROJECT:$VERSION" \
    .

Task: Publish

Now we need to publish the OCI image to our registry. Since we’re only running this CI when pushing a git tag, we can assume the git tag is named after the version we want to set, and because of the setup step we have a handy variable called VERSION that we can use.

Note the use of the --authfile flag here. We’re using the authfile mounted at “~/.auth”, from the secret that we created earlier.

Whenever I push a new version of an image, I also like to push it to the :latest tag, but you can do this however you like.

- publish_oci: |
    # Push version
    sudo podman manifest push \
    --authfile ~/.auth \
    "$PROJECT:$VERSION" \
    "$OCI_REGISTRY/$OCI_REPOSITORY/$PROJECT:$VERSION"

    # Push latest
    sudo podman manifest push \
    --authfile ~/.auth \
    "$PROJECT:$VERSION" \
    "$OCI_REGISTRY/$OCI_REPOSITORY/$PROJECT:latest"

Task: Sign

Now, after we’ve pushed the images, we’ll sign the index using cosign, using the private key we created earlier.

First we need to copy our authfile to “$HOME/.docker/config.json”, since cosign is hardcoded to read the authfile from this location. We’ll also set the environment variable COSIGN_PASSWORD to contain the password to our private key, from the secret that we created earlier. This is a special environment variable that cosign uses, so we don’t have to supply cosign commands with the password. These tasks contains sensitive values, so we’ll encapsulate them in an set +x set -x block.

Then we’ll also use skopeo to get the digest of the OCI index where we pushed our images in the last task. We can use our regular authfile here since skopeo inspect takes the --authfile flag. We’ll name the variable DIGEST. This does not need to be done for both the :$VERSION and the :latest image, since they contain the same images, and have the same digests.

Lastly, we’ll sign the images with cosign, using the digest we got from skopeo and the private key we created earlier. This will push a signature file to the OCI repository, which we can use to verify with our public key later.

- sign_oci: |
    set +x
    mkdir ~/.docker
    cp ~/.auth ~/.docker/config.json
    export COSIGN_PASSWORD=$(cat ~/cosign.password)
    set -x

    DIGEST=$(skopeo inspect --authfile ~/.auth docker://$OCI_REGISTRY/$OCI_REPOSITORY/$PROJECT:$VERSION | jq -r ".Digest")

    cosign sign --yes \
    --key ~/cosign.key \
    "$OCI_REGISTRY/$OCI_REPOSITORY/$PROJECT@$DIGEST"

Complete Build Manifest

Here is the complete file that we’ve written.

---
image: alpine/latest

packages:
  - iptables  # Needed for podman build
  - hugo
  - podman
  - cosign
  - skopeo
  - jq

secrets:
  - 06965d05-4554-4832-8a60-628e1a219a39  # DOCKER_HUB_AUTHFILE
  - f3e67338-52fb-4d8d-aa4d-7529bbf74cef  # COSIGN_KEY
  - a99495b8-32a3-4b37-9c9f-7e6772dbfba2  # COSIGN_PASSWORD

environment:
  PROJECT: grop.dev
  OCI_PLATFORM: linux/amd64,linux/arm64
  OCI_REGISTRY: registry-1.docker.io
  OCI_REPOSITORY: gunnargrop

tasks:
  - setup: |
      # Exit pipeline if NOT triggered by tag
      if [[ "$GIT_REF" != refs/tags/* ]]; then
          complete-build
      fi

      # Set environment variables
      set +x
      cd $PROJECT
      # Let the VERSION variable be the name of the latest git tag
      echo "VERSION=$(git tag --sort=-v:refname | awk '/^\d/' | head -n 1)" >> ~/.buildenv
      set -x

      # Setup for podman, which requires cgroups to function
      sudo rc-update add cgroups
      sudo rc-service cgroups start

  - build_oci: |
      sudo podman manifest create "$PROJECT:$VERSION"

      cd $PROJECT
      sudo podman build \
      --file "Dockerfile" \
      --platform "$OCI_PLATFORM" \
      --manifest "$PROJECT:$VERSION" \
      .

  - publish_oci: |
      # Push version
      sudo podman manifest push \
      --authfile ~/.auth \
      "$PROJECT:$VERSION" \
      "$OCI_REGISTRY/$OCI_REPOSITORY/$PROJECT:$VERSION"

      # Push latest
      sudo podman manifest push \
      --authfile ~/.auth \
      "$PROJECT:$VERSION" \
      "$OCI_REGISTRY/$OCI_REPOSITORY/$PROJECT:latest"

  - sign_oci: |
      set +x
      mkdir ~/.docker
      cp ~/.auth ~/.docker/config.json
      export COSIGN_PASSWORD=$(cat ~/cosign.password)
      set -x

      DIGEST=$(skopeo inspect --authfile ~/.auth docker://$OCI_REGISTRY/$OCI_REPOSITORY/$PROJECT:$VERSION | jq -r ".Digest")

      cosign sign --yes \
      --key ~/cosign.key \
      "$OCI_REGISTRY/$OCI_REPOSITORY/$PROJECT@$DIGEST"

Conclusion

We’re all done! Now when you push a new tag to your git repository, this CI will run, build your images, publish them, and sign them.

Once it’s completed, you can use cosign with your public key to verify that it’s signed by a trusted source. In my case, it would look like this:

cosign verify --key cosign.pub docker.io/gunnargrop/grop.dev:latest

Where I see this output:

Verification for index.docker.io/gunnargrop/grop.dev:latest – The following checks were performed on each of these signatures:

The cosign claims were validated

Existence of the claims in the transparency log was verified offline

The signatures were verified against the specified public key

[ { “critical”: { “identity”: { “docker-reference”: “registry-1.docker.io/gunnargrop/grop.dev” }, “image”: { “docker-manifest-digest”: “sha256:91caaa17007095a67be411215c97d989b127c2c9179df6d72258698361797988” }, “type”: “cosign container image signature” }, “optional”: { “Bundle”: { “SignedEntryTimestamp”: “MEYCIQC0sy5/hKB2+lmJEHOLsyzoDuxG/B9P0sxiOs3wWkozbgIhAMfqqwn/0erKYDc0jRo2x3Cmzd7aNC8oOWOnfUzCaEeb”, “Payload”: { “body”: “eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiJiNWU2ZTQyYjViZWQ2ZmJlMjFlMDZiYzk1ZGFhZGU4MmE4Mjg4MWEyNGVhN2U1NjRmNDk1OTY4MzNkZTUyMzQyIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJUUQrSVFMZzhBTjVJRmh5S09PSEYvcXladWttTHRWZzZTZFR5WlhlaWROcFV3SWdHd2FaS3RHaWJKenVMNi9zQ294c0t0elVPb0h4cC8rYWpFRjAxR0gyV0g4PSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCUVZVSk1TVU1nUzBWWkxTMHRMUzBLVFVacmQwVjNXVWhMYjFwSmVtb3dRMEZSV1VsTGIxcEplbW93UkVGUlkwUlJaMEZGUm1wNVZIVlZaVUYxV1VSVFdXZHJUVWwwT1ZCNk5GWlZVMDFUVFFwTlYydHhRbTV3ZVhCblNXUTNOMUZLUlN0U05FNUNVVGMwWWpReWMzQlVja3hZYWxsV2FGcHJXakl6WVRrdlQyWnpSVzl3UjFGMWVuUjNQVDBLTFMwdExTMUZUa1FnVUZWQ1RFbERJRXRGV1MwdExTMHRDZz09In19fX0=”, “integratedTime”: 1760886624, “logIndex”: 622102447, “logID”: “c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d” } } } } ]

Yay! It works!

If it doesn’t work, if there is no signature at all, or if the signature is by an untrusted source, the output will look like this:

Error: no matching signatures: invalid signature when validating ASN.1 encoded signature error during command execution: no matching signatures: invalid signature when validating ASN.1 encoded signature

Nextcloud OIDC with authentik

Fri, 17 Oct 2025 01:29:00 +0200

Abstract

Recently I’ve been wanting to set up a local Single Sign-On (SSO) for my homelab. There are a lot of great options for Identity and Access Management (IAM) systems, like Keycloak (which probably has the most enterprise support), Authelia, and VoidAuth (which seems really cool and promising).

I’ve chosen to go with authentik, however, for it’s flexibility and ease of use. I’ve really liked it thus far, from it’s easy deployment in Kubernetes to it’s easy customization with Terraform/OpenTofu.

In this blog post I thought I’d share how I setup OpenID Connect (OIDC) authentication for Nextcloud with authentik. And while it’s possible to use LDAP and SAML for Nextcloud (and with authentik), I think OIDC is by far the easiest solution.

One problem that OIDC sometimes have is that clients redirects users to the SSO instead of handling the authentication in the client application (Nextcloud, in this example). This has a tendency not to work with some mobile and desktop applications. This is however not a problem for Nextcloud, since its clients already authenticates users by redirecting them to the Nextcloud server in the web browser first. So, this solution works for both the Nextcloud desktop and mobile applications.

This guide assumes you already have working authentik and Nextcloud instances running.

Configuring authentik

Note: I’ll be configuring authentik with Terraform/OpenTofu, but it should be fairly easy to translate into doing it manually.

View full Terraform example...

// Groups
resource "authentik_group" "nextcloud-admins" {
    name = "Nextcloud Admins"
}

resource "authentik_group" "nextcloud-users" {
    name = "Nextcloud Users"
}

// Builtin property mappings
data "authentik_property_mapping_provider_scope" "default-oauth-email" {
    name = "authentik default OAuth Mapping: OpenID 'email'"
}

data "authentik_property_mapping_provider_scope" "default-oauth-openid" {
    name = "authentik default OAuth Mapping: OpenID 'openid'"
}

data "authentik_property_mapping_provider_scope" "default-oauth-profile" {
    name = "authentik default OAuth Mapping: OpenID 'profile'"
}

// Property Mappings
resource "authentik_property_mapping_provider_scope" "nextcloud-profile" {
    name       = "Nextcloud Profile"
    scope_name = "nextcloud"
    expression = <<EOF
# Extract all groups the user is a member of
groups = [group.name for group in user.ak_groups.all()]

# In Nextcloud, administrators must be members of a fixed group called "admin".
if "Nextcloud Admins" in groups and "admin" not in groups:
    groups.append("admin")

return {
    "name": request.user.name,
    "groups": groups,
    # Set a quota by using the "nextcloud_quota" property in the user's attributes
    "quota": user.group_attributes().get("nextcloud_quota", None),
    # To connect an existing Nextcloud user, set "nextcloud_user_id" to the Nextcloud username.
    "user_id": user.attributes.get("nextcloud_user_id", str(user.uuid)),
}
EOF
}

// Builtin certificate key pairs
data "authentik_certificate_key_pair" "authentik-self-signed-certificate" {
  name = "authentik Self-signed Certificate"
}

// Builtin flows
data "authentik_flow" "default-provider-authorization-explicit-consent" {
  slug = "default-provider-authorization-explicit-consent"
}

data "authentik_flow" "default-provider-invalidation-flow" {
  slug = "default-provider-invalidation-flow"
}

// Provider
resource "authentik_provider_oauth2" "nextcloud" {
    name                  = "Provider for Nextcloud"
    signing_key           = data.authentik_certificate_key_pair.authentik-self-signed-certificate.id
    property_mappings     = [
        data.authentik_property_mapping_provider_scope.default-oauth-email.id,
        data.authentik_property_mapping_provider_scope.default-oauth-openid.id,
        data.authentik_property_mapping_provider_scope.default-oauth-profile.id,
        authentik_property_mapping_provider_scope.nextcloud-profile.id
    ]
    authorization_flow    = data.authentik_flow.default-provider-authorization-implicit-consent.id
    invalidation_flow     = data.authentik_flow.default-provider-invalidation-flow.id
    sub_mode              = "user_uuid"
    allowed_redirect_uris = [
        {
            matching_mode = "strict",
            url           = "https://nextcloud.mars.internal/apps/user_oidc/code",
        },
        {
            matching_mode = "strict",
            url           = "https://nextcloud.eskilstuna.gay/apps/user_oidc/code",
        }
    ]
}

// Application
resource "authentik_application" "nextcloud" {
    name              = "Nextcloud"
    slug              = "nextcloud"
    group             = var.application-groups.pim
    protocol_provider = authentik_provider_oauth2.nextcloud.id
}

// Policy Bindings
resource "authentik_policy_binding" "nextcloud-admins-access" {
    target = authentik_application.nextcloud.uuid
    group  = authentik_group.nextcloud-admins.id
    order  = 0
}

resource "authentik_policy_binding" "nextcloud-users-access" {
    target = authentik_application.nextcloud.uuid
    group  = authentik_group.nextcloud-users.id
    order  = 0
}

Overview

Below is a list of what we need to do in authentik.

Create a user group and an admin group
Create a proprty mapping
Create a OAuth2 provider
Create an application
Create policy bindings for the groups

Creating Groups

I’ve opted for the creating of two groups: “Nextcloud Users” and “Nextcloud Admins”. There’s nothing special about these, you can just create them under “Directory > Groups”.

resource "authentik_group" "nextcloud-admins" {
    name = "Nextcloud Admins"
}

resource "authentik_group" "nextcloud-users" {
    name = "Nextcloud Users"
}

Creating Property Mapping

If we want users in the “Nextcloud Admins” group to actually be administrators in Nextcloud, we need to create a property mapping, since Nextcloud has a built-in admin group called “admin”, which we need to map to our group.

You can create it under “Customization > Property Mappings” and it needs to be of type “Scope Mapping”. It should look something like this.

resource "authentik_property_mapping_provider_scope" "nextcloud-profile" {
    name       = "Nextcloud Profile"
    scope_name = "nextcloud"
    expression = <<EOF
# Extract all groups the user is a member of
groups = [group.name for group in user.ak_groups.all()]

# In Nextcloud, administrators must be members of a fixed group called "admin".
if "Nextcloud Admins" in groups and "admin" not in groups:
    groups.append("admin")

return {
    "name": request.user.name,
    "groups": groups,
    # Set a quota by using the "nextcloud_quota" property in the user's attributes
    "quota": user.group_attributes().get("nextcloud_quota", None),
    # To connect an existing Nextcloud user, set "nextcloud_user_id" to the Nextcloud username.
    "user_id": user.attributes.get("nextcloud_user_id", str(user.uuid)),
}
EOF
}

Creating Provider

Create an OAuth2 provider called “Provider for Nextcloud” under “Applications > Providers”. Take note of the Client ID and Client Secret, since we’ll need them later.

You can use any Signing Key you want, I’ve just used the default self-signed one. Then we’ll use the regular, built-in property mappings for “email”, “openid” and “profile”.

The only thing special about this provider is that we also have to assign the property mapping we created in the previous step (“Nextcloud Profile”), and we’ll set the Subject mode to “Based on the User’s UUID”.

We’ll also set a Redirect URI for “https://nextcloud.example.com/apps/user_oidc/code”.

resource "authentik_provider_oauth2" "nextcloud" {
    name                  = "Provider for Nextcloud"
    signing_key           = data.authentik_certificate_key_pair.authentik-self-signed-certificate.id
    property_mappings     = [
        data.authentik_property_mapping_provider_scope.default-oauth-email.id,
        data.authentik_property_mapping_provider_scope.default-oauth-openid.id,
        data.authentik_property_mapping_provider_scope.default-oauth-profile.id,
        authentik_property_mapping_provider_scope.nextcloud-profile.id
    ]
    authorization_flow    = data.authentik_flow.default-provider-authorization-implicit-consent.id
    invalidation_flow     = data.authentik_flow.default-provider-invalidation-flow.id
    sub_mode              = "user_uuid"
    allowed_redirect_uris = [
        {
            matching_mode = "strict",
            url           = "https://nextcloud.mars.internal/apps/user_oidc/code",
        },
        {
            matching_mode = "strict",
            url           = "https://nextcloud.eskilstuna.gay/apps/user_oidc/code",
        }
    ]
}

You’ll notice that I have two Redirect URIs, but that’s just because I have two URIs that I use to reach my Nextcloud instance.

Creating Application

Create an application under “Applications > Applications” and set the provider to the one we created in the previous step.

resource "authentik_application" "nextcloud" {
    name              = "Nextcloud"
    slug              = "nextcloud"
    protocol_provider = authentik_provider_oauth2.nextcloud.id
}

Creating Policy Bindings

This step isn’t strictly necessary. It just makes sure that only members of our groups, “Nextcloud Users” and “Nextcloud Admins” can authenticate in Nextcloud.

Just go to “Applications > Applications > Nextcloud” and click on “Policy / Group / User Bindings”, then click “Bind existing Policy / Group / User”, choose “Group” and then “Nextcloud Admins”, and set the order to “0”. Then do the same for “Nextcloud Users”.

resource "authentik_policy_binding" "nextcloud-admins-access" {
    target = authentik_application.nextcloud.uuid
    group  = authentik_group.nextcloud-admins.id
    order  = 0
}

resource "authentik_policy_binding" "nextcloud-users-access" {
    target = authentik_application.nextcloud.uuid
    group  = authentik_group.nextcloud-users.id
    order  = 0
}

Configuring Nextcloud

Overview

Below is a list of what we need to do in Nextcloud.

Install the OpenID Connect user backend
Configure the OpenID Connect user backend

Install the OIDC App

Go to “Apps” and install the OpenID Connect user backend.

Configure the OIDC App

Go to “Administration > OpenID Connect” and click the plus icon to register a new OIDC provider.

Client Configuration

Set the following values.

Identifier: “authentik”
Client ID: The Client ID from you Nextcloud provider in authentik
Client Secret: The Client Secret from you Nextcloud provider in authentik
Discovery Endpoint: “https://authentik.example.com/application/o/nextcloud/.well-known/openid-configuration”
Scope: “email profile nextcloud openid”

Note: The “nextcloud” scope here comes from the scope mapping we created in authentik.

Attribute Mapping

Set the following attributes mappings.

User ID mapping: “sub”
Quota mapping: “quota”
Groups mapping: “groups”
Display name mapping: “name”
Email mapping: “email”

Authentication and Access Control Settings

Ensure the following boxes are ticked/enabled.

Use group provisioning
Send ID token hint on logout

Note: Do not tick the “Use unique user ID” box. This will also make it so that every group name that comes from authentik is hashed in Nextcloud, which will also apply to the “admin” group. I.e, this will break the ability for any authentik user to become admin.

Troubleshooting

Local Addresses

If Nextcloud and authentik are running on the same local network, you might have to add this configuration parameter to your config.php file.

'allow_local_remote_servers' => true

This “allows remote servers with local addresses, e.g., in federated shares, webcal services, and more”.

TLS Verification

If you’re using TLS encryption for your authentik instance (which you should!), then you need to make sure that Nextcloud trusts it’s TLS certificate. If you’re not using self-signed certificates you can probably skip this section.

Nextcloud, unlike many applications, does not use the systems CA trust bundle by default. It uses it’s own, usually located at “/var/www/html/resources/config/ca-bundle.crt”.

On Linux Systems

If you’ve installed Nextcloud on a Linux system, then it might be easiest to just add your own CA certificates to the systems CA trust bundle.

# I'll assume you have your CA certificates in a file called ca.crt or ca.pem

# For Debian/Ubuntu systems
sudo cp ca.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

# For SUSE systems
sudo cp ca.pem /etc/pki/trust/anchors
sudo update-ca-certificates

# For RHEL systems
sudo cp ca.pem /etc/pki/ca-trust/source/anchors
sudo update-ca-trust

Then copy the systems trust bundle to Nextcloud.

sudo cp /etc/ssl/certs/ca-certificates.crt /var/www/html/resources/config/ca-bundle.crt

In Kubernetes

If you’ve deployed Nextcloud in Kubernetes, like me, you might want mount a complete trust store directly to the correct path in the pod.

I’m using a trust-manger Bundle resource like this.

Note: Setting “useDefaultCAs: true” is very important if you’re overriding the default Nextcloud trust store. Otherwise Nextcloud will only trust your own CA.

apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: home-internal-ca.crt
spec:
  sources:
  - useDefaultCAs: true # Important!
  - inLine: |
      -----BEGIN CERTIFICATE-----
      MIIBwDCCAWagAwIBAgIRAIbgEVlTCwD5qhf58A6nudwwCgYIKoZIzj0EAwIwPjEZ
      ...
      o3j37R6cxYayBsvmtn2EF9VyvJ0=
      -----END CERTIFICATE-----
  target:
    configMap:
      key: ca.crt
    namespaceSelector:
      matchLabels:
        trust: enabled

Then I’m just setting the label “trust: enabled” on the namespace where Nextcloud is deployed. trust-manger will then create a ConfigMap resource called “home-internal-ca.crt” in the namespace.

apiVersion: v1
kind: Namespace
metadata:
  name: nextcloud
  labels:
    kubernetes.io/metadata.name: nextcloud
    trust: enabled

After that, I just mount the ConfigMap to the correct place in the pod.

Note that I’m using the Nextcloud Helm chart, so this goes in my values.yaml file, but you can easily do the same directly in a Deployment resource.

nextcloud:
  extraVolumes:
    - name: home-internal-ca
      configMap:
        name: home-internal-ca.crt

  extraVolumeMounts:
    # Mounting ConfigMap to systems trust store as well
    # just for good measure
    - name: home-internal-ca
      mountPath: /etc/ssl/certs/ca-certificates.crt
      subPath: ca.crt
      readOnly: true
    - name: home-internal-ca
      mountPath: /var/www/html/resources/config/ca-bundle.crt
      subPath: ca.crt
      readOnly: true

Conclusion

You’re all done! Now you can add yourself or other uses to the “Nextcloud Users” or “Nextcloud Admins” groups in authentik and sign in with them in Nextcloud. If the users don’t already exist in Nextcloud they will be created automatically.

Introductions

Tue, 16 Sep 2025 17:29:00 +0200

My first blog post!

Greetings to everyone and anyone who might be reading this. My name is Gunnar Andersson, also known as my internet nickname, GunnarGrop.

I guess I’m just a typical nerd with an interest in Linux, Emacs and Kubernetes. But if you want to know more about me you can just read my about page.

The reason I wanted to start this blog is because I often stumble upon, to me, interesting facts and solutions to Linux or Kubernetes problems that I’ve wished I’d write down somewhere. So not only is the purpose of this blog to share my thoughts and finding with other people, but also just to share my thought with my future self.

Another reason I wanted to start this blog is simply because I thought it would be fun. I’ve seen this static website generator being mentioned everywhere online, Hugo (which I’m using to generate this blog), and I wanted to try it out. Not only that, but I also wanted to try out a popular Emacs package, ox-hugo. This is of course my first blog post, but being able to write posts at all in org-mode is just so cool!

I’ve experimented a little bit with my setup before taking this blog online, so I’ve also tried the easy-hugo Emacs package. But, to be honest, I think I like ox-hugo way more. Easy-hugo seems like a good project, but it assumes that you’ll be writing Hugo files in Markdown, which is of course fully reasonable (it is the native langauge of Hugo, after all), but it feels like a wasted opportunity to not write in org-mode, when you’re already using Emacs.

Anyway, I’ll try this out for a while and see how I like it. If you’re interested in the stuff I post about, please consider subscribing to my RSS feed or throw me an e-mail! You can find my contact information in the left sidebar. 🙂

Gunnar Grop

Trusting CA certificates in Guix System

Fontconfig problems with Nix on Guix System

Full RSS Feed

NixOS WSL on Corporate Networks

Abstract

Challanges

Installation

The Proxy

Install NixOS

Configure NixOS

Conclusion

Argo CD ApplicationSet with templatePatch

Abstract

Writing ApplicationSets

Conclusion

Related Reads

Publishing Static Sites on sourcehut pages

Abstract

Publishing your Site

Conclusion

Related Reads

Building OCI Images with sourcehut builds

Abstract

Prerequisites

sigstore key pair

Registry authfile

Creating sourcehut Secrets

Task: Setup

Task: Build

Task: Publish

Task: Sign

Complete Build Manifest

Conclusion

Related Reads

Nextcloud OIDC with authentik

Abstract

Configuring authentik

Overview

Creating Groups

Creating Property Mapping

Creating Provider

Creating Application

Creating Policy Bindings

Configuring Nextcloud

Overview

Install the OIDC App

Configure the OIDC App

Client Configuration

Attribute Mapping

Authentication and Access Control Settings

Troubleshooting

Local Addresses

TLS Verification

On Linux Systems

In Kubernetes

Conclusion

Related Reads

Introductions