mirror of
https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk.git
synced 2025-12-05 23:11:40 +01:00
docs(misc): Change to stylized note/warning/important banners
This commit is contained in:
Philip Gaber
@@ -184,8 +184,10 @@ sequenceDiagram
|
||||
Note over Browser: User is authenticated
|
||||
```
|
||||
|
||||
> **Note:**<br>
|
||||
> Nubus' Portal and UMC still use [SAML 2.0](https://www.oasis-open.org/standard/saml/) to authenticate users. However, Nubus will switch to OIDC in an upcoming release, eliminating the use of SAML in openDesk altogether.
|
||||
> [!note]
|
||||
> Nubus' Portal and UMC still use [SAML 2.0](https://www.oasis-open.org/standard/saml/) to authenticate
|
||||
> users. However, Nubus will switch to OIDC in an upcoming release, eliminating the use of SAML in openDesk
|
||||
> altogether.
|
||||
|
||||
## Keycloak
|
||||
|
||||
@@ -245,7 +247,7 @@ To find out more, see [Roles & Permissions](./docs/permissions.md).
|
||||
|
||||
In openDesk, SCIM will be used in the future to automate the process of creating, updating, and deactivating user accounts across the applications. This ensures that user data is consistent across all applications, reducing the administrative overhead and potential for errors.
|
||||
|
||||
> **Note:**<br>
|
||||
> [!note]
|
||||
> SCIM support is planned in openDesk for 2025.
|
||||
|
||||
# Component integration
|
||||
|
||||
@@ -295,8 +295,10 @@ The following are the APIs used by the Groupware application:
|
||||
| Supported standards | SOAP |
|
||||
| Documentation | https://software.open-xchange.com/products/appsuite/doc/SOAP/admin/OX-Admin-SOAP.html |
|
||||
|
||||
> **Note**:
|
||||
> You will find a catalogue of the available services including links to the respective URLs at `/webservices/` within the AppSuite host of your openDesk installation, e.g. https://webmail.myopendesk.tld/webservices/
|
||||
> [!note]
|
||||
> You will find a catalogue of the available services including links to the respective URLs at
|
||||
> `/webservices/` within the AppSuite host of your openDesk installation,
|
||||
> e.g. https://webmail.myopendesk.tld/webservices/
|
||||
|
||||
## REST API
|
||||
|
||||
@@ -648,7 +650,7 @@ The following are the APIs used by the Project management application:
|
||||
|
||||
## Jitsi Meet React SDK
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> Additional SDKs can be found at https://jitsi.github.io/handbook/docs/category/sdks/
|
||||
|
||||
| Name | Meet React SDK |
|
||||
|
||||
@@ -38,7 +38,7 @@ As this is a comprehensive set of requirements most new components will not adhe
|
||||
|
||||
This document can be used to assess the status and possible gaps for a component which might itself be the basis for a decision if a component should be integrated into openDesk by working on closing the identified gaps.
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> Even an already integrated application might not adhere to all aspects of the documented requirements yet.
|
||||
> Closing the gaps for existing applications therefore is an openDesk priority.
|
||||
|
||||
@@ -147,8 +147,9 @@ Please find more context about the topic on the [website of the German CIO](http
|
||||
|
||||
Each vendor must provide a certificate that their product - or the parts of the product relevant for openDesk - complies with at least WCAG 2.1 AA or [BITV 2.0](https://www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Informationstechnik/EU-Webseitenrichtlinie/BGG-und-BITV-2-0/Die-neue-BITV-2-0/die-neue-bitv-2-0_node.html). As the certification and related product improvements are time-consuming the focus of openDesk is that a supplier provides a plan and certification partner (contract) that shows the supplier is working towards the certification. While the aforementioned standard states the priority is the "A" level requirements, the "AA" level must be met at the end of the process.
|
||||
|
||||
> **Note**<br>
|
||||
> Please keep in mind that WCAG 2.2 and 3.0 are work in progress. If you already work on accessibility improvements you might want to take these standards already into consideration.
|
||||
> [!note]
|
||||
> Please keep in mind that WCAG 2.2 and 3.0 are work in progress. If you already work on accessibility
|
||||
> improvements you might want to take these standards already into consideration.
|
||||
|
||||
**Reference:** In the past the [accessibility evaluations](https://gitlab.opencode.de/bmi/opendesk/info/-/tree/main/24.03/Barrierefreiheit) have been executed by Dataport. But they do not do certifications.
|
||||
|
||||
@@ -185,7 +186,7 @@ With a central Identity- and Access Management (IAM) also the user lifecycle (UL
|
||||
|
||||
The focus is to have all the account information in all applications including the account's state, profile picture ([reference](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/issues/27)) and - where required - the user's group memberships. This cannot be done purely by pushing that data through OIDC claims when a user logs in to an application therefore two ways of managing an account are applicable and described in the following subchapters.
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> Allowing ad hoc updates of account data through OIDC claims during login is still encouraged.
|
||||
|
||||
### Pull: LDAP
|
||||
@@ -194,8 +195,9 @@ Applications can access the IAM's LDAP to access all data necessary for managing
|
||||
|
||||
**Reference:** Most applications use LDAP access as per https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/blob/main/docs/components.md?ref_type=heads#identity-data-flows
|
||||
|
||||
> **Note**<br>
|
||||
> The direct access to LDAP is going to be deprecated for most use cases. openDesk is looking into active provisioning of the user/group data into the applications using [SCIM](https://scim.cloud/).
|
||||
> [!note]
|
||||
> The direct access to LDAP is going to be deprecated for most use cases. openDesk is looking into active
|
||||
> provisioning of the user/group data into the applications using [SCIM](https://scim.cloud/).
|
||||
|
||||
### Push: Provisioning
|
||||
|
||||
|
||||
@@ -31,10 +31,10 @@ It will be extended over time as we deal with debugging cases.
|
||||
We for sure do not want to reinvent the wheel, so we might link to external sources that contain helpful
|
||||
information where available.
|
||||
|
||||
> **Warning**<br>
|
||||
> You should never enable the debug option in production environments! By looking up `debug.enabled` in the deployment, you
|
||||
will find the various places changes are applied when enabling debugging. So, outside of development and test
|
||||
environments, you should use them thoughtfully and carefully if needed.
|
||||
> [!warning]
|
||||
> You should never enable the debug option in production environments! By looking up `debug.enabled` in the
|
||||
> deployment, you will find the various places changes are applied when enabling debugging. So, outside of
|
||||
> development and test environments, you should use them thoughtfully and carefully if needed.
|
||||
|
||||
# Enable debugging
|
||||
|
||||
@@ -49,11 +49,13 @@ This will result in:
|
||||
- making the Keycloak admin console available by default at `https://id.<your_domain>/admin/`
|
||||
- ingress for `http://minio-console.<your_domain>` being configured
|
||||
|
||||
> **Note**<br>
|
||||
> When enabling debug mode and updating your deployment, you must manually delete all jobs before updating. In debug mode, we keep the jobs, and some job fields are immutable, leading to a deployment failure.
|
||||
> [!note]
|
||||
> When enabling debug mode and updating your deployment, you must manually delete all jobs before updating. In
|
||||
> debug mode, we keep the jobs, and some job fields are immutable, leading to a deployment failure.
|
||||
|
||||
> **Note**<br>
|
||||
> All containers should write their log output to STDOUT; if you find (valuable) logs inside a container which were not in STDOUT, please let us know!
|
||||
> [!note]
|
||||
> All containers should write their log output to STDOUT; if you find (valuable) logs inside a container which
|
||||
> were not in STDOUT, please let us know!
|
||||
|
||||
# Adding containers to a pod for debugging purposes
|
||||
|
||||
@@ -215,11 +217,16 @@ kubectl patch -n ${NAMESPACE} configmap ${CONFIGMAP_NAME} --type merge -p '{"dat
|
||||
|
||||
2. Restart the Keycloak Pod(s).
|
||||
|
||||
> **Note**<br>
|
||||
> Because the `ums-keycloak-extensions-handler` is sending frequent requests (one per second) to Keycloak for retrieval of the Keycloak event history, you might want to stop/remove the deployment while debugging/analysing Keycloak to not get your debug output spammed by these requests.
|
||||
> [!note]
|
||||
> Because the `ums-keycloak-extensions-handler` is sending frequent requests (one per second) to Keycloak for
|
||||
> retrieval of the Keycloak event history, you might want to stop/remove the deployment while
|
||||
> debugging/analysing Keycloak to not get your debug output spammed by these requests.
|
||||
|
||||
> **Note**<br>
|
||||
> While you can set the standard log levels like `INFO`, `DEBUG`, `TRACE` etc. you can also set class specific logs by comma separating the details in the `KC_LOG_LEVEL` environment variable like e.g. `INFO,org.keycloak.protocol.oidc.endpoints:TRACE`. The example sets the overall loglevel to `INFO` but provides trace logs for `org.keycloak.protocol.oidc.endpoints`.
|
||||
> [!note]
|
||||
> While you can set the standard log levels like `INFO`, `DEBUG`, `TRACE` etc. you can also set class specific
|
||||
> logs by comma separating the details in the `KC_LOG_LEVEL` environment variable like
|
||||
> e.g. `INFO,org.keycloak.protocol.oidc.endpoints:TRACE`. The example sets the overall loglevel to `INFO` but
|
||||
> provides trace logs for `org.keycloak.protocol.oidc.endpoints`.
|
||||
|
||||
### Accessing the Keycloak admin console
|
||||
|
||||
|
||||
@@ -84,9 +84,9 @@ In the project's CI, there is a step dedicated to lint the two yaml files, as we
|
||||
In the linting step, the [openDesk CI CLI](https://gitlab.opencode.de/bmi/opendesk/tooling/opendesk-ci-cli) is used to apply the
|
||||
aforementioned sorting, and the result is compared with the unsorted version. If there is a delta, the linting fails, and you can fix it by running the CLI tool locally, verifying and applying the result to your branch.
|
||||
|
||||
> **Note**<br>
|
||||
> Please ensure that in component blocks, you use comments only at the beginning of the block or at its end. Ideally, you stick
|
||||
with the many available examples in the yaml files.
|
||||
> [!note]
|
||||
> Please ensure that in component blocks, you use comments only at the beginning of the block or at its
|
||||
> end. Ideally, you stick with the many available examples in the yaml files.
|
||||
|
||||
Example:
|
||||
```yaml
|
||||
@@ -126,7 +126,7 @@ Checks for newer versions of the given artifact and creates an MR containing the
|
||||
|
||||
- See also: https://gitlab.opencode.de/bmi/opendesk/tooling/oci-pull-mirror
|
||||
|
||||
> **Note:**<br>
|
||||
> [!note]
|
||||
> The mirror is scheduled to run every hour at 42 minutes past the hour.
|
||||
|
||||
openDesk strives to make all relevant artifacts available on openCode so there is a mirroring process
|
||||
|
||||
@@ -85,7 +85,7 @@ The below rendering in [class diagram](https://en.wikipedia.org/wiki/Class_diagr
|
||||
- the first section below the name of the class shows the required **characteristics** of each component of the given class
|
||||
- the second section shows the **methods** like linting that must be applied to that class's artifacts
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> The methods prefixed with '-' are not yet available in `gitlab-config`. You will learn about them later.
|
||||
|
||||
```mermaid
|
||||
@@ -148,11 +148,14 @@ openDesk uses Apache 2.0 as the license for their work. A typical reuse copyrigh
|
||||
```
|
||||
The way to mark the license header as a comment differs between the various file types. Please find matching examples for all types across the [deployment automation repository](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk).
|
||||
|
||||
> **Note**<br>
|
||||
> If a `SPDX-FileCopyrightText` already exists with the copyright owner described above but with a past year (e.g. 2024), please update this copyright header line to cover (up to and including) the current year, e.g. `2024-2025`.
|
||||
> [!note]
|
||||
> If a `SPDX-FileCopyrightText` already exists with the copyright owner described above but with a past year
|
||||
> (e.g. 2024), please update this copyright header line to cover (up to and including) the current year,
|
||||
> e.g. `2024-2025`.
|
||||
|
||||
> **Note**<br>
|
||||
> If line(s) with `SPDX-FileCopyrightText` containing a different copyright owner exist in the file you are working on, do not replace existing one(s), but rather add another header above these.
|
||||
> [!note]
|
||||
> If line(s) with `SPDX-FileCopyrightText` containing a different copyright owner exist in the file you are
|
||||
> working on, do not replace existing one(s), but rather add another header above these.
|
||||
|
||||
## Development workflow
|
||||
|
||||
@@ -348,14 +351,14 @@ Branches created from the `develop` branch have to adhere to the following notat
|
||||
|
||||
Example: `tmueller/fix_jitsi_theming`.
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> The above naming convention has yet to be enforced, but please ensure you use it.
|
||||
|
||||
#### Commit messages / Conventional Commits
|
||||
|
||||
Commit messages must adhere to the [Conventional Commit standard](https://www.conventionalcommits.org/en/v1.0.0/#summary). Commits that do not adhere to the standard get rejected by either [Gitlab push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html) or the CI.
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> The first letter after the `: ` must be uppercase.
|
||||
|
||||
```text
|
||||
@@ -372,7 +375,7 @@ Commit messages must adhere to the [Conventional Commit standard](https://www.co
|
||||
|
||||
Example: `fix(open-xchange): Bump to 8.26 to heal issue with functional mailbox provisioning.`
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> The commit messages are an essential part of the [technical releases](https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/releases) as the release notes are generated from these messages.
|
||||
|
||||
#### Verified commits
|
||||
|
||||
@@ -44,9 +44,10 @@ References:
|
||||
|
||||
Afterwards, you can use the resulting manifests within a standard Argo CD workflow.
|
||||
|
||||
> **Note**<br>
|
||||
> When creating the Argo CD application based on the resulting manifests, you must not use the `Automated Sync Policy`
|
||||
> offered by Argo CD, as you have to manually ensure the applications are updated in the required sequence.
|
||||
> [!note]
|
||||
> When creating the Argo CD application based on the resulting manifests, you must not use the `Automated Sync
|
||||
> Policy` offered by Argo CD, as you have to manually ensure the applications are updated in the required
|
||||
> sequence.
|
||||
|
||||
## Option 2: Helmfile plugin
|
||||
|
||||
|
||||
@@ -41,8 +41,9 @@ You will have to select an existing user account that will be used as a service
|
||||
|
||||
Please note that the account that shall serve as the service account requires a Microsoft 365/Exchange online license (mailbox).
|
||||
|
||||
> **Note**<br>
|
||||
> If you want to designate your admin account as a service account, you have to provide the admin with a license.
|
||||
> [!note]
|
||||
> If you want to designate your admin account as a service account, you have to provide the admin with a
|
||||
> license.
|
||||
|
||||
***2. Register the audriga app in your tenant***
|
||||
|
||||
@@ -53,7 +54,7 @@ To register the audriga app in your tenant, log into your admin account and acce
|
||||
- Accept the App "audriga CloudMovr migration"
|
||||
- You will be redirected to an audriga page, which you can close - it does not require additional interaction.
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> The audriga application is created under the "Enterprise application" tab in the AzureAD console.
|
||||
|
||||
***3. Create a "secret" group in the M365 tenant***
|
||||
@@ -91,11 +92,15 @@ To validate the master authentication mode please read the appendix section at t
|
||||
|
||||
Updating your deployment with these settings will allow you to continue with the migration scenario. Once the migration is completed, you can remove `secrets.oxAppSuite.migrationsMasterPassword` and need to turn off the migration mode by setting `functional.migration.oxAppSuite.enabled` to `false` or removing that setting, as `false` is the default before you update your deployment once again.
|
||||
|
||||
> **Note**<br>
|
||||
> For the changes to take effect, it is sufficient to re-deploy the `open-xchange` component alone. But you have to restart the Dovecot Pod(s) manually when switching to/from the master authentication mode for the changes to take effect.
|
||||
> [!note]
|
||||
> For the changes to take effect, it is sufficient to re-deploy the `open-xchange` component alone. But you
|
||||
> have to restart the Dovecot Pod(s) manually when switching to/from the master authentication mode for the
|
||||
> changes to take effect.
|
||||
|
||||
> **Note**<br>
|
||||
> While in master authentication mode, regular users cannot log in to the webmail module of openDesk or access the mail using IMAP, as it is not recommended that users interact with the target mail infrastructure during the migration scenario described in this document.
|
||||
> [!note]
|
||||
> While in master authentication mode, regular users cannot log in to the webmail module of openDesk or access
|
||||
> the mail using IMAP, as it is not recommended that users interact with the target mail infrastructure during
|
||||
> the migration scenario described in this document.
|
||||
|
||||
# Migration configuration
|
||||
|
||||
@@ -107,7 +112,7 @@ Ensure you meet the prerequisites. For example, this document does not support u
|
||||
|
||||
Choose [Microsoft 365 / Exchange Online (Admin)](https://umzug.audriga.com/SMESwitchWebApp/?client=groupware#src=onmicrosoft.com) as your current provider.
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> You may need to start typing in "Microsoft Office 365/Exchange Online" for it to appear in the list.
|
||||
|
||||
Configure openDesk as your destination server:
|
||||
|
||||
@@ -152,7 +152,7 @@ If you just created the `fed-test-idp-realm`, you are already in the admin scree
|
||||
|
||||
## openDesk IdP
|
||||
|
||||
> **Note**
|
||||
> [!note]
|
||||
> While manual configuration is possible, an SSO federation can also be configured as part of the deployment.
|
||||
> Check `functional.authentication.ssoFederation` section from the `functional.yaml.gotmpl` for details.
|
||||
|
||||
|
||||
@@ -52,9 +52,9 @@ CA certificate as X.509 encoded (`ca.crt`) and as jks trust store (`truststore.j
|
||||
5. Create a Kubernetes secret with name `opendesk-certificates-keystore-jks` with key `password` and as value the jks
|
||||
trust store password.
|
||||
|
||||
> **Note**<br>
|
||||
> XWiki does not support the use of an existing secret to access the keystore. Therefore you have to set the password
|
||||
> from step 5 also as `secrets.certificates.password`.
|
||||
> [!note]
|
||||
> XWiki does not support the use of an existing secret to access the keystore. Therefore you have to set the
|
||||
> password from step 5 also as `secrets.certificates.password`.
|
||||
|
||||
## Option 2a: Use cert-manager.io with auto-generated namespace based root-certificate
|
||||
|
||||
|
||||
@@ -19,8 +19,10 @@ This document will cover the additional configuration for external services like
|
||||
When deploying this suite to production, you need to configure the applications to use your production-grade database
|
||||
service.
|
||||
|
||||
> **Note**<br>
|
||||
> openDesk supports PostgreSQL as alternative database backend for Nextcloud and XWiki. PostgreSQL is likely to become the preferred option/default in the future should MariaDB become deprecated. This would cause migration[^1] to be necessary if you do not select PostgreSQL for new installations.
|
||||
> [!note]
|
||||
> openDesk supports PostgreSQL as alternative database backend for Nextcloud and XWiki. PostgreSQL is likely
|
||||
> to become the preferred option/default in the future should MariaDB become deprecated. This would cause
|
||||
> migration[^1] to be necessary if you do not select PostgreSQL for new installations.
|
||||
|
||||
| Component | Name | Parameter | Key | Default |
|
||||
| ------------------ | ------------------ | --------- | --------------------------------------------- | ---------------------------- |
|
||||
|
||||
@@ -32,5 +32,9 @@ The following categories are available. Each category contains a set of options
|
||||
|
||||
In case the options from [`functional.yaml.gotmpl`](../helmfile/environments/default/functional.yaml.gotmpl) are not sufficient, you might want to look into [`customization.yaml.gotmpl`](../helmfile/environments/default/customization.yaml.gotmpl). The customizations give you control over all templating that is being done in openDesk, but be aware it is an unsupported approach, so in case you have a strong need for customizations, please let us know by opening a ticket. We will check if it is a use case that can be supported by implementing it as part of the aforementioned [`functional.yaml.gotmpl`](../helmfile/environments/default/functional.yaml.gotmpl).
|
||||
|
||||
> **Note<br>**
|
||||
> You can not directly template your own values in the structure found in [`customization.yaml.gotmpl`](../helmfile/environments/default/customization.yaml.gotmpl), rather, you need to reference your custom value files to overwrite the openDesk defaults. In the app specific `helmfile-child.yaml.gotmpl` files, the openDesk value files are referenced first, then afterwards, the files you define in the customizations are read.
|
||||
> [!note]
|
||||
> You can not directly template your own values in the structure found in
|
||||
> [`customization.yaml.gotmpl`](../helmfile/environments/default/customization.yaml.gotmpl), rather, you need
|
||||
> to reference your custom value files to overwrite the openDesk defaults. In the app specific
|
||||
> `helmfile-child.yaml.gotmpl` files, the openDesk value files are referenced first, then afterwards, the
|
||||
> files you define in the customizations are read.
|
||||
|
||||
@@ -236,9 +236,9 @@ ingress:
|
||||
ingressClassName: "nginx"
|
||||
```
|
||||
|
||||
> **Note**<br>
|
||||
> Currently, the only supported ingress controller is `ingress-nginx`
|
||||
> (see [requirements.md](./docs/requirements.md) for reference).
|
||||
> [!note]
|
||||
> Currently, the only supported ingress controller is `ingress-nginx` (see
|
||||
> [requirements.md](./docs/requirements.md) for reference).
|
||||
|
||||
### Container runtime
|
||||
|
||||
@@ -279,8 +279,9 @@ While openDesk configures the applications with meaningful defaults, you can che
|
||||
|
||||
### Ports
|
||||
|
||||
> **Note**<br>
|
||||
> If you use `NodePort` for service exposure, you must check your deployment for the actual ports and ensure they are opened where necessary.
|
||||
> [!note]
|
||||
> If you use `NodePort` for service exposure, you must check your deployment for the actual ports and ensure
|
||||
> they are opened where necessary.
|
||||
|
||||
#### Web-based user interface
|
||||
|
||||
@@ -385,10 +386,15 @@ To prevent others from using your openDesk instance, you must set your individua
|
||||
export MASTER_PASSWORD="your_individual_master_password"
|
||||
```
|
||||
|
||||
> **Note**<br>
|
||||
> Currently a [documented](https://docs.software-univention.de/nubus-kubernetes-operation/1.x/en/configuration/nats.html#configure-the-secrets) upstream [bug](https://forge.univention.org/bugzilla/show_bug.cgi?id=58357) causes a failure when passwords/secrets beginning with certain numbers are using for the Nubus subcomponent NATS.
|
||||
> With openDesk 1.6.0 an update-aware workaround was implemented that prefixes the affected secrets in the openDesk included `secrets.yaml.gotmpl` that derives all secrets from the previously mentioned `MASTER_PASSWORD`.
|
||||
> If you are using externally provided passwords/secrets make sure that none of the ones listed below are starting with a number:
|
||||
> [!important]
|
||||
> Currently a
|
||||
> [documented](https://docs.software-univention.de/nubus-kubernetes-operation/1.x/en/configuration/nats.html#configure-the-secrets)
|
||||
> upstream [bug](https://forge.univention.org/bugzilla/show_bug.cgi?id=58357) causes a failure when
|
||||
> passwords/secrets beginning with certain numbers are using for the Nubus subcomponent NATS. With openDesk
|
||||
> 1.6.0 an update-aware workaround was implemented that prefixes the affected secrets in the openDesk included
|
||||
> `secrets.yaml.gotmpl` that derives all secrets from the previously mentioned `MASTER_PASSWORD`. If you are
|
||||
> using externally provided passwords/secrets make sure that none of the ones listed below are starting with a
|
||||
> number:
|
||||
>
|
||||
> - `secrets.nubus.provisioning.api.natsPassword`
|
||||
> - `secrets.nubus.provisioning.dispatcherNatsPassword`
|
||||
@@ -497,7 +503,7 @@ You can uninstall the deployment by executing the following:
|
||||
helmfile destroy -n <NAMESPACE>
|
||||
```
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> Not all Jobs, PersistentVolumeClaims, or Certificates are deleted; you have to delete them manually
|
||||
|
||||
**'Sledgehammer destroy'** - for fast development turn-around times (at your own risk):
|
||||
@@ -516,5 +522,5 @@ kubectl delete jobs --all --namespace ${NAMESPACE};
|
||||
kubectl delete configmaps --all --namespace ${NAMESPACE};
|
||||
```
|
||||
|
||||
> **Warning**<br>
|
||||
> [!warning]
|
||||
> Without specifying a `--namespace` flag, or by leaving it empty, cluster-wide components will get deleted!
|
||||
|
||||
@@ -52,8 +52,9 @@ Roles are defined sets of permissions that can be assigned to users. Each role c
|
||||
- **openDesk Administrator**: Manages openDesk-global settings, such as users and groups.
|
||||
- **openDesk User**: Can log in to openDesk to make use of defined openDesk applications.
|
||||
|
||||
> **Note**<br>
|
||||
> Although it is not enforced by openDesk, it is strongly recommended that a user account is not granted both roles at the same time. This is to maintain the separation of duties.
|
||||
> [!note]
|
||||
> Although it is not enforced by openDesk, it is strongly recommended that a user account is not granted both
|
||||
> roles at the same time. This is to maintain the separation of duties.
|
||||
|
||||
### Application usage
|
||||
|
||||
@@ -93,15 +94,20 @@ When editing a user in the IAM, you can select if a user can access or get eleva
|
||||
|
||||
To easily identify these groups, all of them are prefixed with `managed-by-Attribute-`.
|
||||
|
||||
> **Note**<br>
|
||||
> The membership of these groups is automatically managed based on the user's attributes from the "openDesk" tab. Any changes directly to the groups will be overwritten, so please always use the "openDesk" tab of the respective user. The IAM supports editing user attributes across multiple accounts simultaneously.
|
||||
> [!note]
|
||||
> The membership of these groups is automatically managed based on the user's attributes from the "openDesk"
|
||||
> tab. Any changes directly to the groups will be overwritten, so please always use the "openDesk" tab of the
|
||||
> respective user. The IAM supports editing user attributes across multiple accounts simultaneously.
|
||||
|
||||
#### Standard access to applications
|
||||
|
||||
Unless a user is a member of a group, the respective application is not shown in the portal.
|
||||
|
||||
> **Note**<br>
|
||||
> In openDesk's identity provider, the required OIDC claims to access an application are only granted when the respective group membership is available. This means that even if a user who is not a member of an application group knows the link to the application and calls it directly, the single sign-on will be unsuccessful.
|
||||
> [!note]
|
||||
> In openDesk's identity provider, the required OIDC claims to access an application are only granted when the
|
||||
> respective group membership is available. This means that even if a user who is not a member of an
|
||||
> application group knows the link to the application and calls it directly, the single sign-on will be
|
||||
> unsuccessful.
|
||||
|
||||
- **managed-by-Attribute-Groupware**: Members of this group have access to the groupware applications.
|
||||
- **managed-by-Attribute-Fileshare**: Members of this group have access to the file sharing application.
|
||||
@@ -130,7 +136,7 @@ Users get roles assigned based on their responsibilities and the tasks they need
|
||||
|
||||
openDesk defines [templates](https://gitlab.opencode.de/bmi/opendesk/components/platform-development/images/opendesk-nubus/-/blob/main/udm/udm-data-loader/65-usertemplate.yaml) for the *User* and *Administrator* roles. The templates can be used by an *openDesk Administrator* to create users with these roles using the [administration portal](https://docs.opendesk.eu/administration/).
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> Additional/custom templates can be created using the UDM REST API.
|
||||
|
||||
### *openDesk User*
|
||||
@@ -195,8 +201,10 @@ Managing all application permissions within the IAM would require a superset of
|
||||
|
||||
Within IAM groups, the visibility of openDesk applications can be configured. Like with users, this is done in the "openDesk" tab of the [group administration](https://docs.opendesk.eu/administration/gruppen/).
|
||||
|
||||
> **Note**<br>
|
||||
> Currently the openDesk applications do not support nested groups. As a result only direct group memberships of users are processed in the application.<br>
|
||||
> The plan is to enable the openDesk applications to either support nested groups or to actively provision users into an application while resolving the nested group memberships for the application.
|
||||
> [!note]
|
||||
> Currently the openDesk applications do not support nested groups. As a result only direct group memberships
|
||||
> of users are processed in the application.<br> The plan is to enable the openDesk applications to either
|
||||
> support nested groups or to actively provision users into an application while resolving the nested group
|
||||
> memberships for the application.
|
||||
|
||||
Within an application, each available group can have a set of application specific permissions assigned.
|
||||
|
||||
@@ -34,7 +34,10 @@ openDesk follows a structured release cycle to ensure predictability and reliabi
|
||||
| **Minor** | Monthly | New features, enhancements, may contain breaking changes or refactors (clearly flagged in the notes) |
|
||||
| **Patch** | On demand | Bug fixes, security updates, minor improvements, no intended breaking changes |
|
||||
|
||||
> **Note:** openDesk does **not** guarantee that minor releases are 100% backward‑compatible. When a breaking change is unavoidable it is announced in the release notes under a dedicated header **“Breaking Changes”** and a migration guide is provided.
|
||||
> [!note]
|
||||
> openDesk does **not** guarantee that minor releases are 100% backward‑compatible. When a breaking > change
|
||||
> is unavoidable it is announced in the release notes under a dedicated header **“Breaking Changes”** > and a
|
||||
> migration guide is provided.
|
||||
|
||||
## Release schedule
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ Any self-hosted or managed K8s cluster >= v1.24 listed in
|
||||
|
||||
The deployment is tested against [kubespray](https://github.com/kubernetes-sigs/kubespray) based clusters.
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> The deployment is not tested against OpenShift.
|
||||
|
||||
# Ingress controller
|
||||
@@ -67,7 +67,7 @@ configured ingress controller deployed in your cluster.
|
||||
|
||||
- [Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx)
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> The platform development team is evaluating the use of [Gateway API](https://gateway-api.sigs.k8s.io/).
|
||||
|
||||
**Compatibility with Ingress NGINX >= 1.12.0**
|
||||
@@ -79,8 +79,9 @@ controller.config.strict-validate-path-type=false
|
||||
```
|
||||
See the [`annotations-risk-level` documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#annotations-risk-level) and [`strict-validate-path-type` documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#strict-validate-path-type) for details.
|
||||
|
||||
> **Important Note**<br>
|
||||
> Ensure to install at least Ingress NGINX 1.11.5 or 1.12.1 due to [security issues](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities) in earlier versions.
|
||||
> [!warning]
|
||||
> Ensure to install at least Ingress NGINX 1.11.5 or 1.12.1 due to [security
|
||||
> issues](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities) in earlier versions.
|
||||
|
||||
## Minimal configuration
|
||||
|
||||
@@ -96,7 +97,7 @@ See the [`allowSnippetAnnotations` documentation](https://kubernetes.github.io/i
|
||||
Initial evaluation deployment requires a `ReadWriteOnce` volume provisioner. For local deployment, a local- or hostPath-
|
||||
provisioner is sufficient.
|
||||
|
||||
> **Note**<br>
|
||||
> [!note]
|
||||
> Some components require a `ReadWriteMany` volume provisioner for distributed mode or horizontal scaling.
|
||||
|
||||
# Certificate management
|
||||
|
||||
@@ -20,9 +20,9 @@ Please review the default configuration that is applied to understand your custo
|
||||
|
||||
You can just update the files in [helmfile/files/theme](../helmfile/files/theme) to change logos, favicons etc. Note that the `.svg` versions of the favicons are also used for the portal tiles.
|
||||
|
||||
> **Note**<br>
|
||||
> Theming focuses on colors, iconography and imagery. If you like to adapt the default links in the portal pointing to external
|
||||
> resources (like "Support", "Legal Notice") please check the `functional.portal` section
|
||||
> [!note]
|
||||
> Theming focuses on colors, iconography and imagery. If you like to adapt the default links in the portal
|
||||
> pointing to external resources (like "Support", "Legal Notice") please check the `functional.portal` section
|
||||
> in [`functional.yaml.gotmpl`](../helmfile/environments/default/functional.yaml.gotmpl)
|
||||
|
||||
# Known limitations
|
||||
|
||||
Reference in New Issue
Block a user