#nomad #openbao #jenkins #homelab

I have two automatic/system jobs that require a Token.

• The backup cron job is taking Nomad snapshots in regular intervals. The snapshot API requires a management token and the Nomad policy capability for snapshots with the operator are not implemented yet.
• The Jenkins server runs Nomad jobs using the Nomad cloud plugin. This system needs a Token to access the Nomad API (AppRole not compatible, see below).

I still keep my bootstrapping token around just in case I ever need it. That's ok unlike to procedures with OpenBao root tokens..

The bootstrap token can be deleted and is like any other token, care should be taken to not revoke all management tokens.

Name             Type        Global  Accessor ID  Expired
Bootstrap Token  management  true    ***          false
Snapshot         management  false   ***          false
OIDC-vault       client      true    ***          false
Jenkins          client      false   ***          false

The auth method in Nomad is still called Vault, never mind..

The access for human users is authenticated by an OIDC provider in my OpenBao server.

Because I already had an identity and alias setup (userpass authentication) including a group, I only needed to configure the provider and the assignment to the group to allow authentication with the new provider.

In the OpenBao server, the default provider and the allow_all assignment cannot be deleted. I assume it is similar to the “master” realm in a Keycloak instance 🤔.

I had to define a NOMAD_TOKEN as “Jenkins credential”, because the Nomad cloud plugin for Jenkins cannot read secrets from OpenBao using an AppRole (the Nomad jobs spawned by the plugin can do this, just not the plugin itself).

When I type nomad login in the shell, the browser opens and I can authenticate with OpenBao. What could be improved is outputting the OIDC redirect URI in the terminal. This is helpful when you need to login from disconnected machines (i.e., not the shell on your local machine).