Infrastructure profiles

An environment is rarely one thing. "Staging" is two web servers, a database, an AWS account, and a Kubernetes namespace. An infrastructure profile gives that set a name.

The problem it solves is onboarding. Without profiles, a new engineer is handed a list of aliases and told which ones are staging. With them, they are told one word.

shortspan profile list
shortspan profile enter staging

enter lists every resource the profile grants and the command to reach each one:

Profile: staging

  SSH
    staging-web-1        shortspan ssh staging-web-1
    staging-web-2        shortspan ssh staging-web-2

  Databases
    staging-db           shortspan db staging-db --via staging-web-1

  AWS
    staging              shortspan aws staging

  Kubernetes
    staging-cluster      shortspan k8s staging-cluster

Entering a profile is itself recorded, which makes "who was working in staging last Thursday" answerable without reading every individual credential release.

Profiles are assembled in the console under Infrastructure → Profiles, or through the API. An admin names the profile and selects which registered resources belong to it. A resource can be in several profiles; a profile can be empty while it is being built.

A profile grants nothing on its own. It is a view over resources you already have access to, so two people entering the same profile can see different things - which is correct, and worth knowing before you use one to explain an environment to someone.

• Name profiles after environments, not teams. staging outlives platform-team.

• Keep one profile per project rather than one profile spanning projects - the project is the access boundary, and a profile that crosses it will look inconsistent to anyone with access to only one side.

• Include the bastion in the profile even though nobody connects to it directly. --via needs it registered, and its absence from the list is the first thing that confuses a new engineer.