ADR on how to secure the Fleet-manager (control plane) admin end-point

[akoserwal]

What ADR on how to secure the Fleet-manager (control plane) admin end-point

Authorization for control plane admin APIs

The JWT token contains the necessary roles, which are used by the control plane to make authorization decisions Currently, these roles are present in the SRE realm and assigned manually to users (Ex: CS-SRE engineers get admin read access)

Roles: read, write, full permissions

SRE realm will be migrated to RH Internal authentication system. Roles with being mapped to rover groups. The authorization mechanism will remain the same for the fleet manager by changing the identity provider to RH Internal authentication system

[akoserwal]

@emmanuelbernard @tombentley

[tombentley]

Hi @akoserwal, I have a couple of questions:

• Is this KAS fleet manager specifically, or fleet managers in general?
• Can you write the ADR avoiding details of RH internal authentication systems? It's only if the RH-specifics have architectural consequences that this gets tricky. If the things driving architectural choices are general things which any oauth-consumer might experience then an ADR is a good place to discus.

Thanks!

[akoserwal]

• Is this KAS fleet manager specifically, or fleet managers in general?

  General: Fleet manager (Kafka, Connectors,ACS)

• Can you write the ADR avoiding details of RH internal authentication systems? It's only if the RH-specifics have architectural consequences that this gets tricky. If the things driving architectural choices are general things which any oauth-consumer might experience then an ADR is a good place to discus.

• yes, a generic pattern can be written for OAuth-consumers

• Using the reference above pattern, I can write a document which can be shared internally that covers RH internal authentication system details.

[tombentley]

@akoserwal I've merged https://github.com/bf2fc6cc711aee1a0c2a/architecture/pull/72 for you to start writing the content.