LTS service accounts

An LTS service account is a regular account with zero storage allocation, owned by a particular user, for the purposes of CI/CD automation interacting with LTS.

How to configure?

• Create a new access/secret key pair in LTS (a new special allocation type)
• Set storage quota to zero bytes
• Set comment to indicate BlazerID of who owns it

Limitations?

• Zero storage allocation
• Owners must be supervisors (Research Lab Supervisor or Core Director)
• Owners are responsible for granting the service account access to data in LTS via bucket policies, we will not ever grant a service account attached to an existing allocation (i.e., as alternative keys for that allocation)
• Owners are responsible for understanding and implementing

Good practices for use?

• Principle of least privilege: only grant the service account access to the data it needs access to, either using bucket policy scoping, or a separate bucket entirely.
• Principle of least function: only use the service account in repos where it is needed.
• We can talk if you believe you need more than one service account.
• Protect your keys using CI/CD variables (https://docs.gitlab.com/ci/variables/#protect-a-cicd-variable)
• Do not ever use your primary allocation keys as CI/CD variables. If they are compromised, all of your data would be compromised. Only ever use service accounts.

Start by reviewing the devops-docs repository and the LTS service-account requirements in this issue. Document how to create the key pair, configure zero storage, identify the owner, apply the listed limitations and least-privilege practices, and complete the unfinished responsibility statement; the work is done when the configuration and safe CI/CD usage guidance are clear.