sheppy/opendesk
1
0
Fork 0
mirror of https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk.git synced 2025-12-06 15:31:38 +01:00
Code Issues Packages Projects Releases Wiki Activity

fix(docs): Various updates

Browse Source
This commit is contained in:
Thorsten Roßner
2024-03-18 15:04:51 +01:00
parent 0fd4a26c71
commit 50e263866b
7 changed files with 39 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/components.md
View File

@@ -1,5 +1,6 @@
<!--
SPDX-FileCopyrightText: 2023 Bundesministerium des Innern und für Heimat, PG ZenDiS "Projektgruppe für Aufbau ZenDiS"
SPDX-FileCopyrightText: 2024 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH
SPDX-License-Identifier: Apache-2.0
-->
<h1>Components</h1>
@@ -34,7 +35,6 @@ they need to be replaced in production deployments.
| ClamAV (Simple) | Antivirus engine | Eval |
| Collabora | Weboffice | Functional |
| CryptPad | Weboffice | Functional |
| Dovecot | Mail backend | Functional |
| Element | Secure communications platform | Functional |
| Intercom Service | Cross service data exchange | Functional |
| Jitsi | Videoconferencing | Functional |
@@ -44,7 +44,8 @@ they need to be replaced in production deployments.
| Nextcloud | File share | Functional |
| OpenProject | Project management | Functional |
| OX Appsuite | Groupware | Functional |
| Provisioning | Backend provisioning | Functional |
| OX Dovecot | Mail backend (IMAP) | Functional |
| Provisioning (OX Connector) | Groupware provisioning | Functional |
| Postfix | MTA | Eval |
| PostgreSQL | Database | Eval |
| Redis | Cache Database | Eval |

13
docs/development.md
View File

@@ -1,5 +1,6 @@
<!--
SPDX-FileCopyrightText: 2024 Bundesministerium des Innern und für Heimat, PG ZenDiS "Projektgruppe für Aufbau ZenDiS"
SPDX-FileCopyrightText: 2024 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH
SPDX-License-Identifier: Apache-2.0
-->
@@ -32,7 +33,7 @@ flowchart TD
D-->G[images.yaml]
D-->H[global.*]
D-->I[secrets.yaml\nreplicas.yaml\nresources.yaml\n...]
A-->|overwrite defaults with\nyour environment specific values|E[./helmfile/environments/*your_environment*/values.yaml.gotmpl]
A-->|overwrite defaults with your\ndeployment/environment specific values|E[./helmfile/environments/*your_environment*/values.yaml.gotmpl]
```
The `helmfile.yaml` in the root folder is the basis for the whole deployment. It references the app specific `helmfile.yaml` files as well as some
@@ -96,13 +97,13 @@ Example:
## Renovate
- See also: https://gitlab.opencode.de/bmi/opendesk/tooling/renovate-opencode
Uses a regular expression to match the values of the following attributes:
Uses a regular expression to match the values of the attributes
- `# upstreamRegistry`
- `# upstreamRepository`
- `registry`
- `repository`
- `tag`
check for newer versions of the given artefact and create a MR containing the newest version's tag (and digest).
Checks for newer versions of the given artefact and creates a MR containing the newest version's tag (and digest).
## Mirroring

23
docs/workflow.md
View File

@@ -1,5 +1,6 @@
<!--
SPDX-FileCopyrightText: 2023 Bundesministerium des Innern und für Heimat, PG ZenDiS "Projektgruppe für Aufbau ZenDiS"
SPDX-FileCopyrightText: 2024 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH
SPDX-License-Identifier: Apache-2.0
-->
@@ -139,17 +140,19 @@ As a standard, the openDesk platform development team uses [reuse.software](http
openDesk uses Apache 2.0 as the license for their work. A typical reuse copyright and license header looks like this:
```
# SPDX-FileCopyrightText: 2023 Bundesministerium des Innern und für Heimat, PG ZenDiS "Projektgruppe für Aufbau ZenDiS"
# SPDX-FileCopyrightText: 2024 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH
# SPDX-License-Identifier: Apache-2.0
```
As the way to mark the license header as a comment differs between the various filetypes, please find matching examples for the types all across the [deployment automation repository](https://gitlab.opencode.de/bmi/souveraener_arbeitsplatz/deployment/sovereign-workplace).
**Remark**: If there is already an existing `SPDX-FileCopyrightText` please just add the one from the above example.
## Development workflow
### Disclaimer
openDesk consists only of community products, so there is no SLA to receive service updates or backports of critical security fixes. This has two consequences:
- In production scenarios, you should replace the community versions of the functional components with supported, SLA-backend paid versions.
- In production scenarios, you should replace the community versions of the functional components with supported, SLA-backed paid versions.
- openDesk aims to always update to the latest available releases of the community components and we therefore have rolling technical releases.
### Workflow
@@ -225,22 +228,28 @@ gitGraph
The Standard Quality Gate addresses quality assurance steps that should be executed within each of the mentioned quality gates in the workflow.
1. Linting
- Blocking
- Licening: [reuse](https://github.com/fsfe/reuse-tool)
- openDesk specific: Especially `images.yaml` and `charts.yaml`, find more details in the [development](./development.md) docu
- Non Blocking
- Security: [Kyverno policy check](../.kyverno) addressing some IT-Grundschutz requirements
- Formal: Yaml
1. Deploy the full openDesk stack from scratch:
- All deployment steps must be successful (green)
- All tests from the end-to-end test set must be successful
2. Update deployment[^3] of the full openDesk stack and apply the quality measures from the step #1:
1. Update deployment[^3] of the full openDesk stack and apply the quality measures from the step #1:
- Deploy the current merge target baseline (`develop` or `main`)
- Update deploy from your QA branch into the instance from the previous step
3. No showstopper found regarding
1. No showstopper found regarding
- SBOM compliance[^4]
- Malware check
- CVE check[^5]
- Kubescape scan[^5]
- Kyverno policy check (also covering some basic requirements from IT-Grundschutz)[^5]
Steps #1 and #2 from above are executed as GitLab CI and therefore documented within GitLab.
Steps #1 to #3 from above are executed as GitLab CI and therefore documented within GitLab.
Step #3 is focussed on security and was not fully implemented yet. Its main objective is to check for regressions. That step is just the second step of a security check and monitoring chain as shown below. While some checks can be executed against the static artefacts (e.g. container images) other might require an up-and-running instance. These are especially located in the third step below which is not yet implemented.
Step #4 is focussed on security and was not fully implemented yet. Its main objective is to check for regressions. That step is just the second step of a security check and monitoring chain as shown below. While some checks can be executed against the static artefacts (e.g. container images) other might require an up-and-running instance. These are especially located in the third step below which is not yet implemented.
```mermaid
flowchart TD