Skip to content

Commit daf781e

Browse files
abhijith-darshanLicense Bot
abhijith-darshan
and
License Bot
authored
feat: refactor ADR(s) to conform with MADR style (#8)
* chore: adds log4brains configuration initialize adr folder with log4brains * chore: update readme update README with how to use log4brains * fix: typo revert to adr file name consisting three digits * refactor: new adr template refactor the ADR template to be compatible with the styel of MADR https://adr.github.io/madr/ * chore: remove files * refactor: update ADR-1 ADR-1 is refactored to conform with MADR style * chore: adds gitignore file Add gitignore file with common ignoring for editor configs * chore: removes emoji ratings in ADR-1 * refactor: update ADR-2 ADR-2 is refactored to conform with MADR style * refactor: rename ADR-1 * refactor: rename ADR-3 ADR-3 is refactored to conform with MADR style * fix: rectifies indentation in template * refactor: removes a redundant section * refactor: update ADR-5 ADR-5 is refactored to conform with MADR style. Misc style changes are introduced in this commit for all ADR(s). * chore: Adds index page When visualized via log4brains UI an index page is added to describe greenhouse ADR(s) * chore: updates README keeps file names in example in lowercase * fix: update checkout action Add the missing repository and ref to checkout action * Automatic application of license header * chore: adds ADR(s) timelines Adds creation date of ADR(s) * chore: Adr Makefile Adds Makefile to easily lint and create new ADR(s) and updates README for Makefile usage * fix: double prints on make commands --------- Co-authored-by: License Bot <[email protected]>
1 parent d978ece commit daf781e

17 files changed

+943
-726
lines changed

‎.github/workflows/license.yaml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -15,6 +15,8 @@ jobs:
1515
uses: actions/checkout@v4
1616
with:
1717
token: ${{ secrets.GITHUB_TOKEN }}
18+
repository: ${{ github.event.pull_request.head.repo.full_name }}
19+
ref: ${{ github.event.pull_request.head.ref }}
1820

1921
- name: Check License Header
2022
uses: apache/skywalking-eyes/[email protected]

‎.gitignore

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
/.local/
2+
# Mac OS
3+
.DS_Store
4+
# IDEs and editors
5+
.idea
6+
.project
7+
.classpath
8+
.c9/
9+
*.launch
10+
.settings/
11+
*.sublime-workspace
12+
# ignore vscode debug binary
13+
__debug_bin
14+
15+
# ignore vscode workspaces of individual users
16+
*.code-workspace
17+
18+
# IDE - VSCode
19+
.vscode/*
20+
!.vscode/settings.json
21+
!.vscode/tasks.json
22+
!.vscode/launch.json
23+
!.vscode/extensions.json
24+
25+
# editor and IDE paraphernalia
26+
*.swp
27+
*.swo
28+
*~
29+
*.bkp
30+
*.dtmp

‎.log4brains.yml

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
# SPDX-FileCopyrightText: 2024 SAP SE or an SAP affiliate company and Greenhouse contributors
2+
# SPDX-License-Identifier: Apache-2.0
3+
4+
project:
5+
name: Greenhouse
6+
tz: Europe/Berlin
7+
adrFolder: architecture-decision-records
8+
packages: []

‎Makefile

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
# SPDX-FileCopyrightText: 2024 SAP SE or an SAP affiliate company and Greenhouse contributors
2+
# SPDX-License-Identifier: Apache-2.0
3+
4+
PREFIX ?=greenhouse
5+
TITLE ?=
6+
docsFolder=architecture-decision-records
7+
LC_PREFIX=$(shell echo $(PREFIX) | tr '[:upper:]' '[:lower:]')
8+
LC_TITLE=$(shell echo $(TITLE) | tr '[:upper:]' '[:lower:]')
9+
10+
.PHONY: check
11+
check:
12+
@if [ -z "$(LC_TITLE)" ]; then \
13+
echo "TITLE is required. Please provide a title using make init TITLE=Your Title Here"; \
14+
exit 1; \
15+
fi
16+
@echo "$(LC_TITLE)" | grep -qE "^[a-zA-Z0-9-]+$$" || { \
17+
echo "TITLE contains invalid characters. Only alphanumeric characters and hyphens are allowed."; \
18+
exit 1; \
19+
}
20+
21+
.PHONY: init
22+
init: check
23+
@echo "Checking for Node.js..."
24+
@command -v node >/dev/null 2>&1 || { echo >&2 "Node.js is not installed. Please install Node.js."; exit 1; }
25+
@echo "Checking for log4brains..."
26+
@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; }
27+
$(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))
28+
$(eval NEW_INDEX=$(shell printf "%03d" $$((10#$(MAX_INDEX) + 1))))
29+
@echo "Next ADR index: $(NEW_INDEX)"
30+
@echo "Creating new ADR with title prefix $(NEW_INDEX)-$(LC_PREFIX)-$(LC_TITLE).md"
31+
$(eval ADR_TITLE=$(shell echo "$(NEW_INDEX)-$(LC_PREFIX)-$(LC_TITLE)"))
32+
$(eval GENERATED_FILE=$(shell log4brains adr new --quiet $(ADR_TITLE)))
33+
@mv "${docsFolder}/${GENERATED_FILE}.md" "${docsFolder}/$(ADR_TITLE).md"

‎architecture-decision-records/001-greenhouse-logical-authorization-concept-for-greenhouse-plugins.md

Lines changed: 193 additions & 0 deletions
Large diffs are not rendered by default.

‎architecture-decision-records/002-greenhouse-technical-implementation-of-access-authorization-for-plugins.md

Lines changed: 120 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,120 @@
1+
# 002 Technical Implementation of access Authorization for Greenhouse Plugins
2+
3+
- Status: draft
4+
- Deciders: Fabian Ruff, Esther Schmitz, Arno Uhlig, Uwe Mayer, David Rochow
5+
- Date: 2023-03-09
6+
- Tags: greenhouse
7+
8+
## Context and Problem Statement
9+
10+
Greenhouse is a Platform that aims to aggregate a variety of Applications into a single Platform using a Plugin Concept
11+
that allows Applications to be integrated into Greenhouse while being maintained and developed in a distributed manner.
12+
13+
Furthermore, it intentionally does not support multi-tenancy across Plugin Instances to enable segregation between
14+
tenants and make the Platform usable by totally unrelated LoB's.
15+
16+
This Decision record is about the technical solution how we do Authorizations for Plugins.
17+
18+
## Decision Drivers
19+
20+
- Enables support of multiple Identity Providers
21+
* To allow Organizations to use their own IdP
22+
- Open for adoption
23+
* allows also Plugin Backends to be used that are not developed internally
24+
- Support of Role Mapping within Greenhouse
25+
* Supports the usage for the considered solutions of ADR-1
26+
- Supports running Greenhouse components in a single Kubernetes Cluster
27+
* On kubernetes you can only configure one OIDC Provider
28+
- Implementation effort
29+
- Maintenance effort
30+
31+
## Considered Options
32+
33+
- Team Sync during Deployment
34+
- Team Sync by Plugin during runtime
35+
- Usage of internal IdP for Group Ownership Rewriting based on Greenhouse mappings
36+
37+
## Decision Outcome
38+
39+
Chosen option: **"Usage of internal IdP for Group Ownership Rewriting based on Greenhouse mappings"**
40+
41+
### Positive Consequences
42+
43+
- Overall best decision driver ratings
44+
- Most flexible solution
45+
- Does not require additional syncing of mappings between Greenhouse and Plugins
46+
- We are in control of the OIDC Provider that is used for Authorization of Requests on Plugins
47+
- The authentication is still happening on the external Identity Provider
48+
- Only of the Solutions that solves the Kubernetes problem(just supports one OIDC Provider) by design
49+
50+
### Negative Consequences
51+
52+
- Introduction of an additional Open Source Project
53+
- In case we need to support Plugin Backends outside Converged Cloud, we would need to expose the internal OIDC
54+
Provider (somehow) or build an additional proxy solution.
55+
- This solution is expected to require the most implementation and maintenance effort
56+
57+
## Pros and Cons of the Options
58+
59+
### Team Sync during Deployment
60+
61+
![](./assets/a0b55e95-8ded-47bb-96ce-67729b3f123c.png)
62+
63+
This Solution is using an external OIDC Provider.
64+
Within Greenhouse, mappings from OIDC Groups to Plugin Permissions are done,
65+
and the respective mappings are distributed to Plugins during the deployment of the Plugins.
66+
67+
This means any change in the mapping of a Team/Role would require a re-deployment of the Plugins to happen.
68+
69+
| Decision Driver | Rating | Reason |
70+
|-----------------------------------------------------------------------|--------|-----------------------------------------------------------------------------------------------------------------------------|
71+
| Enables support of multiple Identity Providers | + | possible |
72+
| Open for adoption | + | Would use 100% standard OIDC for Authorization on Plugin Side. Organizations would be forced to use a OIDC Provider though. |
73+
| Support of Role Mapping within Greenhouse | + | supports with variations in the details all options |
74+
| Supports running Greenhouse components in a single Kubernetes Cluster | - | unclear, how this would be solved |
75+
| Implementation effort | o | |
76+
| Maintenance effort | - | The required redeployment of components |
77+
78+
### Team Sync by Plugin during runtime
79+
80+
![](./assets/c652bfd8-2552-4eea-9e1a-89ee1a078e69.png)
81+
82+
In this Solution we use a external OIDC provider as well.
83+
The mapping of Access Levels for Plugins is also done within Greenhouse.
84+
The difference is that the mapping of OIDC Groups to permissions is fetched from the Plugin at runtime from
85+
Greenhouse using API endpoint implemented for this purpose.
86+
87+
| Decision Driver | Rating | Reason |
88+
|-----------------------------------------------------------------------|--------|----------------------------------------------------------------------------------------|
89+
| Enables support of multiple Identity Providers | + | possible |
90+
| Open for adoption | - | Would use for the Authorization a custom implementation through retrieving the mapping |
91+
| Support of Role Mapping within Greenhouse | + | supports with variations in the implementation details all options |
92+
| Supports running Greenhouse components in a single Kubernetes Cluster | - | unclear how this would be solved |
93+
| Implementation effort | - | We would need to create an additional API Endpoint |
94+
| Maintenance effort | o | Neutral |
95+
96+
### Usage of internal IdP for Group Ownership Rewriting based on Greenhouse mappings
97+
98+
![](./assets/7f365a58-5c96-4648-8c15-d53b32e5b3f7.png)
99+
100+
This Solution does use a federated IdP that handles the authorization.
101+
The Idea here is to us any external Authentication Provider (which could also be something else than an OIDC provider)
102+
and use an internal OIDC Provider that is used for the Plugins and Kubernetes.
103+
Within the internal OIDC Provider, we can then create the Group to Role mappings for plugins before issuing a token.
104+
This way, the token would include all custom Permission mappings that we configure in Greenhouse using a standardized
105+
approach.
106+
This also means that Plugins can either advertise their expected naming schema with their Plugin Schema or
107+
use a default pre-defined schema that all Greenhouse Plugins are using.
108+
109+
| Decision Driver | Rating | Reason |
110+
|-----------------------------------------------------------------------|--------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
111+
| Enables support of multiple Identity Providers | +++ | Even allows usage of other Protocols than OIDC |
112+
| Open for adoption | +++ | Openness for different Identity providers enables Organizations to have a very flexible choice |
113+
| Support of Role Mapping within Greenhouse | + | Supports all the variants |
114+
| 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 |
115+
| Implementation effort | - | Probably more effort to implement than other solutions |
116+
| Maintenance effort | - | Probably more maintenance effort than the other solutions especially due to the additional open source dependencies introduced |
117+
118+
## Related Decision Records
119+
120+
**001 Logical Authorization Concept for Greenhouse Plugins**

0 commit comments

Comments
 (0)