From fd143f9f1767f286fc82a5b5c117737327a5bdcd Mon Sep 17 00:00:00 2001 From: Gerrit Date: Thu, 21 Mar 2024 15:56:38 +0100 Subject: [PATCH] More adaptions. --- docs/src/development/proposals/MEP4/README.md | 27 ++++++++++--------- 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/docs/src/development/proposals/MEP4/README.md b/docs/src/development/proposals/MEP4/README.md index a41f89bf0c..5065d963ab 100644 --- a/docs/src/development/proposals/MEP4/README.md +++ b/docs/src/development/proposals/MEP4/README.md @@ -31,13 +31,17 @@ These are some general requirements / higher objectives that MEP-4 has to fulfil - Simple to start with, more complex options for production setups - Should utilize auth mechanisms that we have already in place to best possible degree - Fine-grained access permissions (every endpoint maps to a permission) -- Tenant scoping (disallow resource access to resources of other tenants, except a user acts "on-behalf") -- Project scoping (disallow resource access to resources of other projects, except a user acts "on-behalf") +- Tenant scoping (disallow resource access to resources of other tenants) +- Project scoping (disallow resource access to resources of other projects) - Access tokens in self-service for technical user access +Non-goals: + +- Provide "tenant acts on-behalf" functionality (because we want only admins and these can act on-behalf) + ## Implementation -We gathered a lot of knowledge while implementing the backend for metalstack.cloud. The goal is now to use the same technology and adopt that to the metal-api, this includes: +We gathered a lot of knowledge while implementing a multi-tenancy-capable backend for metalstack.cloud. The goal is now to use the same technology and adopt that to the metal-api, this includes: - gRPC in combination with connectrpc - OPA for making auth decisions @@ -51,16 +55,19 @@ This repository contains the `proto3` specification of the exposed metal-stack a Client implementations for the most relevant languages (go, python) are generated automatically. -This api is divided into end user and admin access at the top level. The proposed APIs are: +This api is divided into end-user and admin access at the top level. The proposed APIs are: - `api.v2`: For end-user facing services - `admin.v2`: For operators and controllers which need access to unscoped entities -The methods of the API can have different role scope: +The methods of the API can have different role scopes (and can be narrowed down further with fine-grained method permissions): - `tenant`: Tenant-scoped methods, e.g. project creation (tenant needs to be provided in the request payload) + - Available roles: VIEWER, EDITOR, OWNER - `project`: Project-scoped methods, e.g. machine creation (tenant needs to be provided in the request payload) + - Available roles: VIEWER, EDITOR, OWNER - `admin` Admin-scoped methods, e.g. unscoped tenant list or switch register + - Available roles: VIEWER, EDITOR And has methods with different visibility scopes: @@ -78,18 +85,14 @@ With these tokens, users can create Access Tokens for CI/CD or other use cases. JWT Tokens can be revoked by admins and the user itself. -❓ Discuss: Should we create a new repository (https://github.com/metal-stack/api-server) or can we locate the new API in the existing metal-api project beneath v2. - -#### Relationship to the metal-api - -To allow consumers to migrate to the `v2` API gradually, the business logic of the metal-api must be maintained in parallel with the new `v2` api. - -To achieve this with it is required to extract the backend implementation, currently the `cmd/internal` package should be factored out to a consumable repository at `github.com/metal-stack/api-server/pkg/`. We will try to migrate the rethinkdb backend implementation to a generic approach during this effort. +❓ Discuss: Should we create a new repository (https://github.com/metal-stack/api-server) or can we locate the new API in the existing metal-api project beneath `v2`? ### Migration of the Consumers To allow consumers to migrate to the `v2` API gradually, both apis, the new and the old, are deployed in parallel. In the control-plane both apis are deployed side-by-side behind the ingress. `api.example.com` is forwarded to `metal-api` and `metal.example.com` is forwarded to the new `api-server`. +The the business logic of the metal-api must be maintained during the switch to the new `v2` api. To achieve this with it is required to extract the backend implementation, currently the `cmd/internal` package should be factored out to a consumable repository at `github.com/metal-stack/api-server/pkg/`. We will try to migrate the rethinkdb backend implementation to a generic approach during this effort. + There are a lot of consumers of metal-api, which need to be migrated: - ansible