Request a means of using it without requiring a service user account

[astayleraz]

e.g. create a GitHub app that can be deployed to an organization that has permission, or it’s own tokens that allow for non-human use.

I was asked to open an issue with fuzzbucket requesting a means of using it without requiring a service user account as we are trying to create a Jenkins service user for our team.

[meatballhat]

I'd like to introduce a delegated/robot account concept that I think will strike a reasonable balance between convenience and security. Feedback wanted! (pinging @astayleraz @jspiewak @statik)

⚠️ The commands shown below are proposed/aspirational vaporware ⚠️

As an existing logged-in human user, one would create a "robot" account like this:

fuzzbucket-client create-robot bb8 path/to/id_ed25519_bb8.pub

This command would ensure that the robot account and given SSH public key are created and then write a new entry to ~/.cache/fuzzbucket/credentials that could be used locally:

fuzzbucket-client create --name applepie2 --as-robot bb8 ubuntu22

On the server side, this robot account would be authenticated via the secret provided by the client and also the human associated with the robot would be checked via the auth provider (GitHub, Okta, etc.). In this way, the human would still be required to exist and authorize access, but the robot credentials and SSH key pair could be used in an automation context:

$ fuzzbucket-client export-robot bb8
FUZZBUCKET_CREDENTIALS=humanperson+bb8:td6LoVGlcYL5yVEdWFBllO83rPdhNMpSpvDVQOn6MX

Other approaches that I thought would be less great:

• statically-defined (non-expiring) user:secret credentials via deployment configuration
• creation of standalone robot accounts via API with non-expiring credentials stored in the database

[jspiewak]

The downside of continued association between the human and robot is that should the human win the lottery and no longer work for Posit, build automations might cease to work.

[meatballhat]

@jspiewak this is true! Is it acceptable? Would it be better (convenience/security wise) to support non-expiring standalone robot accounts?

[jspiewak]

My preference would be to start with non-expiring tokens for robot accounts, and to then consider enhancing it with expiring tokens that an authorized human user is able to generate, and to keep robots unassociated with the human who created it (other than to record who create it).

All this being said, if Okta is supported, the IDE team has a service account user there (rstudio-ide-test@posit.co). That user could be used to create the robot account so that the authorization browser flow is not needed from a CI pipeline.

[meatballhat]

Given that I'm planning to get the IDE team's deployment of fuzzbucket migrated to one that uses Okta, I'll focus on getting the rstudio-ide-test@posit.co account working before considering any further changes 👍🏼