Sudo

sudoers is not a separate rule language here. cardinal-agent renders /etc/sudoers.d/50-cardinal from the same Cedar policy that decides everything else, and validates it with visudo -c before installing it. A file that fails validation is never written.

cardinal-agent sudoers          # print what would be installed, install nothing

Grant it with a rule:

cardinal policy rule add run-as-root -group sre -to prod

NOPASSWD, and why that is not laziness

Whoever the rule reaches gets ALL=(ALL:ALL) NOPASSWD: ALL on the matching machines.

Cardinal has no passwords, so a rule demanding one prompts for a credential that cannot exist. What gates sudo is the shell: the only way to have one as this person is a certificate issued minutes ago after a device-bound passkey ceremony. The authentication happened; it happened at issuance rather than at the sudo prompt.

Policy adds a second clock on top:

@id("root-requires-recent-auth")
forbid (principal, action == RunAsRoot, resource)
unless { principal.authAgeSeconds <= 900 };

Keep the rule narrow

Sudo is the grant people ask for casually and revisit never, so an example that starts permissive is one that stays permissive. The shipped rule names a specific group and a specific host group deliberately, and the rule builder makes -anything loud for the same reason.

What this does not do

There is no per-command sudoers support: no "may run systemctl restart nginx and nothing else". A rule grants root on a machine or it does not.