This is a spike that will inform the implementation of this epic.

Requirements

• Allow only agents booted from the same ISO to register with the assisted-service and use the agent endpoints
• Agents already know the InfraEnv ID, so if read access requires authentication then that is sufficient in some existing auth schemes.

• Prevent access to write endpoints except by the internal systemd services
• Use some kind of authentication for read endpoints
• Ideally use existing credentials - admin-kubeconfig client cert and/or kubeadmin-password

• (Future) Allow UI access in interactive mode only

Are there any requirements specific to the auth token?

• Ephemeral
• Limited to one cluster

Reuse the existing admin-kubeconfig client cert

Actors:

• Agent Installer: example wait-for
• Internal systemd: configurations, create cluster infraenv, etc
• UI: interactive user
• User: advanced automation user (not supported yet)

Do we need more than one auth scheme?

Agent-admin – agent-read-write

Agent-user – agent-read

Implementation Options

1. New authn scheme in assisted-service
2. Reverse proxy in front of assisted-service API
3. Use an existing auth scheme in assisted-service

Definition of done:

1. List of API endpoints for agent based installation (Automated and Interactive)
2. Decision on what credentials to use for this auth scheme
3. Decision on which implementation option (1,2 or 3)