generated from cloudoperators/repository-template
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into adr/cluster-onboarding
- Loading branch information
Showing
18 changed files
with
952 additions
and
723 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| /.local/ | ||
| # Mac OS | ||
| .DS_Store | ||
| # IDEs and editors | ||
| .idea | ||
| .project | ||
| .classpath | ||
| .c9/ | ||
| *.launch | ||
| .settings/ | ||
| *.sublime-workspace | ||
| # ignore vscode debug binary | ||
| __debug_bin | ||
|
|
||
| # ignore vscode workspaces of individual users | ||
| *.code-workspace | ||
|
|
||
| # IDE - VSCode | ||
| .vscode/* | ||
| !.vscode/settings.json | ||
| !.vscode/tasks.json | ||
| !.vscode/launch.json | ||
| !.vscode/extensions.json | ||
|
|
||
| # editor and IDE paraphernalia | ||
| *.swp | ||
| *.swo | ||
| *~ | ||
| *.bkp | ||
| *.dtmp |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| # SPDX-FileCopyrightText: 2024 SAP SE or an SAP affiliate company and Greenhouse contributors | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| project: | ||
| name: Greenhouse | ||
| tz: Europe/Berlin | ||
| adrFolder: architecture-decision-records | ||
| packages: [] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| # SPDX-FileCopyrightText: 2024 SAP SE or an SAP affiliate company and Greenhouse contributors | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| PREFIX ?=greenhouse | ||
| TITLE ?= | ||
| docsFolder=architecture-decision-records | ||
| LC_PREFIX=$(shell echo $(PREFIX) | tr '[:upper:]' '[:lower:]') | ||
| LC_TITLE=$(shell echo $(TITLE) | tr '[:upper:]' '[:lower:]') | ||
|
|
||
| .PHONY: check | ||
| check: | ||
| @if [ -z "$(LC_TITLE)" ]; then \ | ||
| echo "TITLE is required. Please provide a title using make init TITLE=Your Title Here"; \ | ||
| exit 1; \ | ||
| fi | ||
| @echo "$(LC_TITLE)" | grep -qE "^[a-zA-Z0-9-]+$$" || { \ | ||
| echo "TITLE contains invalid characters. Only alphanumeric characters and hyphens are allowed."; \ | ||
| exit 1; \ | ||
| } | ||
|
|
||
| .PHONY: init | ||
| init: check | ||
| @echo "Checking for Node.js..." | ||
| @command -v node >/dev/null 2>&1 || { echo >&2 "Node.js is not installed. Please install Node.js."; exit 1; } | ||
| @echo "Checking for log4brains..." | ||
| @command -v log4brains >/dev/null 2>&1 || { echo >&2 "log4brains is not installed globally. Please install it by running 'npm install -g log4brains'."; exit 1; } | ||
| $(eval MAX_INDEX=$(shell find ${docsFolder} -name '[0-9][0-9][0-9]-*.md' | sed 's/.*\/\([0-9][0-9][0-9]\)-.*/\1/' | sort -n | tail -1)) | ||
| $(eval NEW_INDEX=$(shell printf "%03d" $$((10#$(MAX_INDEX) + 1)))) | ||
| @echo "Next ADR index: $(NEW_INDEX)" | ||
| @echo "Creating new ADR with title prefix $(NEW_INDEX)-$(LC_PREFIX)-$(LC_TITLE).md" | ||
| $(eval ADR_TITLE=$(shell echo "$(NEW_INDEX)-$(LC_PREFIX)-$(LC_TITLE)")) | ||
| $(eval GENERATED_FILE=$(shell log4brains adr new --quiet $(ADR_TITLE))) | ||
| @mv "${docsFolder}/${GENERATED_FILE}.md" "${docsFolder}/$(ADR_TITLE).md" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
193 changes: 193 additions & 0 deletions
193
...-records/001-greenhouse-logical-authorization-concept-for-greenhouse-plugins.md
Large diffs are not rendered by default.
Oops, something went wrong.
120 changes: 120 additions & 0 deletions
120
.../002-greenhouse-technical-implementation-of-access-authorization-for-plugins.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,120 @@ | ||
| # 002 Technical Implementation of access Authorization for Greenhouse Plugins | ||
|
|
||
| - Status: draft | ||
| - Deciders: Fabian Ruff, Esther Schmitz, Arno Uhlig, Uwe Mayer, David Rochow | ||
| - Date: 2023-03-09 | ||
| - Tags: greenhouse | ||
|
|
||
| ## Context and Problem Statement | ||
|
|
||
| Greenhouse is a Platform that aims to aggregate a variety of Applications into a single Platform using a Plugin Concept | ||
| that allows Applications to be integrated into Greenhouse while being maintained and developed in a distributed manner. | ||
|
|
||
| Furthermore, it intentionally does not support multi-tenancy across Plugin Instances to enable segregation between | ||
| tenants and make the Platform usable by totally unrelated LoB's. | ||
|
|
||
| This Decision record is about the technical solution how we do Authorizations for Plugins. | ||
|
|
||
| ## Decision Drivers | ||
|
|
||
| - Enables support of multiple Identity Providers | ||
| * To allow Organizations to use their own IdP | ||
| - Open for adoption | ||
| * allows also Plugin Backends to be used that are not developed internally | ||
| - Support of Role Mapping within Greenhouse | ||
| * Supports the usage for the considered solutions of ADR-1 | ||
| - Supports running Greenhouse components in a single Kubernetes Cluster | ||
| * On kubernetes you can only configure one OIDC Provider | ||
| - Implementation effort | ||
| - Maintenance effort | ||
|
|
||
| ## Considered Options | ||
|
|
||
| - Team Sync during Deployment | ||
| - Team Sync by Plugin during runtime | ||
| - Usage of internal IdP for Group Ownership Rewriting based on Greenhouse mappings | ||
|
|
||
| ## Decision Outcome | ||
|
|
||
| Chosen option: **"Usage of internal IdP for Group Ownership Rewriting based on Greenhouse mappings"** | ||
|
|
||
| ### Positive Consequences | ||
|
|
||
| - Overall best decision driver ratings | ||
| - Most flexible solution | ||
| - Does not require additional syncing of mappings between Greenhouse and Plugins | ||
| - We are in control of the OIDC Provider that is used for Authorization of Requests on Plugins | ||
| - The authentication is still happening on the external Identity Provider | ||
| - Only of the Solutions that solves the Kubernetes problem(just supports one OIDC Provider) by design | ||
|
|
||
| ### Negative Consequences | ||
|
|
||
| - Introduction of an additional Open Source Project | ||
| - In case we need to support Plugin Backends outside Converged Cloud, we would need to expose the internal OIDC | ||
| Provider (somehow) or build an additional proxy solution. | ||
| - This solution is expected to require the most implementation and maintenance effort | ||
|
|
||
| ## Pros and Cons of the Options | ||
|
|
||
| ### Team Sync during Deployment | ||
|
|
||
|  | ||
|
|
||
| This Solution is using an external OIDC Provider. | ||
| Within Greenhouse, mappings from OIDC Groups to Plugin Permissions are done, | ||
| and the respective mappings are distributed to Plugins during the deployment of the Plugins. | ||
|
|
||
| This means any change in the mapping of a Team/Role would require a re-deployment of the Plugins to happen. | ||
|
|
||
| | Decision Driver | Rating | Reason | | ||
| |-----------------------------------------------------------------------|--------|-----------------------------------------------------------------------------------------------------------------------------| | ||
| | Enables support of multiple Identity Providers | + | possible | | ||
| | Open for adoption | + | Would use 100% standard OIDC for Authorization on Plugin Side. Organizations would be forced to use a OIDC Provider though. | | ||
| | Support of Role Mapping within Greenhouse | + | supports with variations in the details all options | | ||
| | Supports running Greenhouse components in a single Kubernetes Cluster | - | unclear, how this would be solved | | ||
| | Implementation effort | o | | | ||
| | Maintenance effort | - | The required redeployment of components | | ||
|
|
||
| ### Team Sync by Plugin during runtime | ||
|
|
||
|  | ||
|
|
||
| In this Solution we use a external OIDC provider as well. | ||
| The mapping of Access Levels for Plugins is also done within Greenhouse. | ||
| The difference is that the mapping of OIDC Groups to permissions is fetched from the Plugin at runtime from | ||
| Greenhouse using API endpoint implemented for this purpose. | ||
|
|
||
| | Decision Driver | Rating | Reason | | ||
| |-----------------------------------------------------------------------|--------|----------------------------------------------------------------------------------------| | ||
| | Enables support of multiple Identity Providers | + | possible | | ||
| | Open for adoption | - | Would use for the Authorization a custom implementation through retrieving the mapping | | ||
| | Support of Role Mapping within Greenhouse | + | supports with variations in the implementation details all options | | ||
| | Supports running Greenhouse components in a single Kubernetes Cluster | - | unclear how this would be solved | | ||
| | Implementation effort | - | We would need to create an additional API Endpoint | | ||
| | Maintenance effort | o | Neutral | | ||
|
|
||
| ### Usage of internal IdP for Group Ownership Rewriting based on Greenhouse mappings | ||
|
|
||
|  | ||
|
|
||
| This Solution does use a federated IdP that handles the authorization. | ||
| The Idea here is to us any external Authentication Provider (which could also be something else than an OIDC provider) | ||
| and use an internal OIDC Provider that is used for the Plugins and Kubernetes. | ||
| Within the internal OIDC Provider, we can then create the Group to Role mappings for plugins before issuing a token. | ||
| This way, the token would include all custom Permission mappings that we configure in Greenhouse using a standardized | ||
| approach. | ||
| This also means that Plugins can either advertise their expected naming schema with their Plugin Schema or | ||
| use a default pre-defined schema that all Greenhouse Plugins are using. | ||
|
|
||
| | Decision Driver | Rating | Reason | | ||
| |-----------------------------------------------------------------------|--------|------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | Enables support of multiple Identity Providers | +++ | Even allows usage of other Protocols than OIDC | | ||
| | Open for adoption | +++ | Openness for different Identity providers enables Organizations to have a very flexible choice | | ||
| | Support of Role Mapping within Greenhouse | + | Supports all the variants | | ||
| | Supports running Greenhouse components in a single Kubernetes Cluster | +++ | We would internally use only our internal OIDC Provider for issuing tokens which would solve the problem that Kubernetes Clusters only support one OIDC Provider | | ||
| | Implementation effort | - | Probably more effort to implement than other solutions | | ||
| | Maintenance effort | - | Probably more maintenance effort than the other solutions especially due to the additional open source dependencies introduced | | ||
|
|
||
| ## Related Decision Records | ||
|
|
||
| **001 Logical Authorization Concept for Greenhouse Plugins** |
Oops, something went wrong.