Admin UI ‐ cedarling middleware

Expand the admin ui so its the central piece to easily connect and control an organizations third party developer and infrastructure tools such as kubernetes. The below is taking one example on which is Kubernetes access control.

graph TD
    subgraph "User Interaction"
        U(👨‍💻 User)
        WB(Web Portal / K8s View)
    end

    subgraph "Authentication (IAM)"
        JANS(Jans/Flex)
    end

    subgraph "Backend & Authorization"
        TMS(Terminal Management Service)
        CAW(Cedarling Authorizer <br/> Webhook Service)
        PDP(Cedarling PDP <br/> Policy Engine)
    end

    subgraph "Kubernetes Cluster"
        API(K8s API Server)
    end

    U -- "1. Access Portal" --> WB
    WB -- "2. Redirect for Login" --> JANS
    JANS -- "3. Issues JWT" --> U
    U -- "4. Presents JWT to Portal" --> WB

    WB -- "5. Request Authorized Clusters" --> TMS
    TMS -- "6. Query: Can user list clusters?" --> PDP
    PDP -- "7. Decision: Allow/Deny" --> TMS
    TMS -- "8. Returns Authorized List" --> WB
    WB -- "9. Displays Cluster List to User" --> U

    U -- "10. Selects Cluster & Runs Command <br/> e.g., 'kubectl get pods'" --> WB
    WB -- "11. Relays Command to Cluster" --> API

    API -- "12. Authorization Webhook Request <br/> (SubjectAccessReview)" --> CAW
    CAW -- "13. Policy Query: <br/> Can user 'get' 'pods'?" --> PDP
    PDP -- "14. Decision: Allow/Deny" --> CAW
    CAW -- "15. Webhook Response" --> API
    API -- "16. Enforces Decision & <br/> Returns Output/Error" --> WB
    WB -- "17. Displays Result in Terminal" --> U

    subgraph "Admin Functions"
        ADMIN(👩‍💼 Admin User)
        ADMIN_UI(Policy Management UI)
    end
    
    ADMIN -- "Manages Policies" --> ADMIN_UI
    ADMIN_UI -- "Updates Policies" --> PDP

Loading

Shortly, my thoughts is administer a view where the user logins first through jans/flex and gets a k8s view web terminal. Here we have already gone through the initial cedarling process and we don't have to parse or pass the JWT through any kind of wrapper. The user then sees all the clusters they can connect to and run a web terminal to. All the access control is seen and managed using policies with cedarling.

Requirements

1. Admin ui org internal path. We do need to separate the view for developers to be able to access the admin ui.
2. Add an admin view. The admin view would include the settings to enable and disable tools like kubernetes and would allow the admin to connect to the existing kubernetes clusters. Hook up the policies that would be designed in Agama lab.
3. Add a developer view. The developer view contains the tools they can use within the organization. For kubernetes they would be able to see the clusters they are allowed to interact with and be able to initiate a web terminal with kubectl and appropriate permissions mapped automatically.
4. Develop the associated third party necessities or connectors. For kubernetes that would be we would need to design and document the admission web hook controller that would be working to facilitate applying the allow or deny rules in the kuberentes cluster.