Epic Goal

• This epic scope was originally to encompass both authentication and authorization but we have split the expanding scope into a separate epic.
• We want to add authorization to the internal components of Agent Installer so that the cluster install is secure. 

Why is this important?

• The Agent Installer API server (assisted-service) has several methods for Authorization but none of the existing methods are applicable tothe Agent Installer use case. 
• During the MVP of Agent Installer we attempted to turn on the existing authorization schemes but found we didn't have access to the correct API calls.
• Without proper authorization it is possible for an unauthorized node to be added to the cluster during install. Currently we expect this to be done as a mistake rather than maliciously.

Brainstorming Notes:

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

Options for Implementation:

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

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Previous Work (Optional):

1. AGENT-60 Originally we wanted to just turn on local authorization for Agent Installer workflows. It was discovered this was not sufficient for our use case.

Open questions::

1. Which API endpoints do we need for the interactive flow?
2. What auth scheme does the Assisted UI use if any?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>