Access control #

We want to enable users to have more fine-grained control over what pubkeys have access to what pico services.

We accomplish access control using SSH certificates. In particular, there's a principals field that we can leverage for role-based access. When an admin generates a key for a teammate, a limited-access machine, or a robot user, they can specify which services they have access to within the principals field.

Workflow #

The owner of the pico account must generate and manage their own ssh certificate. We will never have access to the private key.

 1# admin creates ssh ca keypair (or uses one they already have)
 2ssh-keygen -t ed25519 -f ./ca_user_ed25519 -C "pico-ca"
 3
 4# alice generates a normal ssh keypair (or uses one they already have)
 5# alice sends pubkey to admin
 6ssh-keygen -t ed25519 -f alice -C "alice@example.com"
 7
 8# admin signs alice pubkey with admin ca private key to produce the user certificate
 9# this generates a new cert-signed pubkey: `alice-cert.pub`
10ssh-keygen -s ./ca_user_ed25519 \
11           -I "alice@$(date +%F)" \
12           -n tuns,pgs \ # this grants alice access to those services
13           -V +52w \
14           alice.pub
15
16# admin sends alice-cert.pub to alice and then they can use their keypair
17# note: you don't normally need to provide the `-o CertificateFile=` since ssh will find it automatically
18# but we wanted to include for completeness
19rsync -e "ssh -i ./alice -o CertificateFile=./alice-cert.pub" -rv ./public/ pgs:/site/

If a user has pico in their principals then they have access to the TUI, but not the ability to generate keys or modify public keys.

Only an admin in principals has full access to pico account management.

Principals:

• admin
• pico
• pgs
• tuns
• pipe
• feeds
• prose
• pastes

Revocation #

We will provide the admin with the ability to revoke public key access to their account services. Admins will be able to control revocations in the TUI.

Team Accounts #

With this feature it could theoretically support teams to use pico. An admin can generate keys and send them to users so they can perform actions on behalf of the account.

There are no limits on number of users or restrictions on usage at this point in time.

This will not change the behavior of the subdomains we create. They will still exist under the primary user name.

The value for -I flag will be sent throughout our logs so admins can see what "user" performed an action.