Merge commit '7b9cb0bdf0d55095064020c9fa27c4079aae762c'

maxwolfs · maxwolfs · commit 57fdecd5fb94 · 2022-11-20T18:06:50.000+01:00
diff --git a/docs/scs-docs/Design-Docs/Release-Numbering-Scheme.md b/docs/scs-docs/Design-Docs/Release-Numbering-Scheme.md
@@ -5,9 +5,9 @@ authors: Christian Berendt, Ralf Heiringhoff
 state: Draft
 ---
 
-# Numbering scheme of the releases versions
+## Numbering scheme of the releases versions
 
-## Motivation & Goals
+### Motivation & Goals
 
 In order to have a common understanding of how release versioning works,
 we wanted to create a support document to make it easier to use.
@@ -18,7 +18,7 @@ updates and different schedules per channel in mind.
 Regardless, we still require operators to read the release notes for
 certain features, bug fixes, and sometimes inevitable breaking changes.
 
-## Release Tags vs Release Version
+### Release Tags vs Release Version
 
 The release tags (R0, R1, ...) of the SCS point to their corresponding
 release version, which can change if, for example, a later hotfix
@@ -27,28 +27,32 @@ version is deemed necessary.
 Think of the "Release Tag" as the name and the "Release Version" as the
 point in time.
 
-## Numbering Syntax
+### Numbering Syntax
 
+```xml
 > v\<ongoing release version>.\<channel>.\<ongoing hotfix version>
+```
 
-### Regex
+#### Regex
 
+```regex
 > v\[0-9\]+.\[0-9\].\[0-9\]+
+```
 
-### Channels
+#### Channels
 
 future use is tbd = atm fixed value of 0
 
-## Examples
+### Examples
 
-<img src="Release-Numbering-Scheme.png" width="50%" alt="Release Versioning Example">
+![Release Versioning Example](Release-Numbering-Scheme.png)
 
 |         | **v42.0.0** | **v42.0.3** | ... | **v47.0.0** |
-|---------|-------------|-------------|-----|-------------|
+| ------- | ----------- | ----------- | --- | ----------- |
 | version | 42          | 42          |     | 47          |
 | channel | 0           | 0           |     | 0           |
 | hotfix  | 0           | 3           |     | 0           |
 
-## Relationship between Release Versions and Subproject Versioning
+### Relationship between Release Versions and Subproject Versioning
 
 tbd. see GH-28
diff --git a/docs/scs-docs/Design-Docs/nbde.md b/docs/scs-docs/Design-Docs/nbde.md
@@ -17,31 +17,30 @@ against access data to data on storage media in case of lost or vendor lifecycle
 ## Proposal
 
 NBDE should be an optional security feature for the SouvereignCloudStack's infrastructure,
-to handle certification like C5 
+to handle certification like C5
 
 ## Technical requirements and features
 
 the involved components:
-    
-* clevis -  is a JOSE'based pluggable framework which is handled automated luks encryption local 
-            inside the boot procedure an is able to handle network base encryption or combine it
-            other methods.
 
-            https://github.com/latchset/clevis
-                          
-* tang  -   is a small webserver with the Jose library, which  is able response to clevis prepared
-            encryption.chain and save  it as a key answer it with a advertisement request, Tang 
-            relies on the JSON Object Signing and Encryption (JOSE) standards
-           
-            https://github.com/latchset/tang
+- clevis - is a JOSE'based pluggable framework which is handled automated luks encryption local
+    inside the boot procedure an is able to handle network base encryption or combine it
+    other methods.
 
-* Jose -    is the Javascript Object Signing and Encryption  Framework, in NBDE context it.
-            use an rsa based. Encryption.
-            https://jose.readthedocs.io/
+                https://github.com/latchset/clevis
 
-* LUKS -    is Linux Unified Key Setup and in Version 2 the default Linux Disk Encryption
+- tang - is a small webserver with the Jose library, which is able response to clevis prepared
+    encryption.chain and save it as a key answer it with a advertisement request, Tang
+    relies on the JSON Object Signing and Encryption (JOSE) standards
 
+                https://github.com/latchset/tang
 
-* NBDE -    in detailed overview and boot procedure
+- Jose - is the Javascript Object Signing and Encryption Framework, in NBDE context it.
+    use an rsa based. Encryption.
+    <https://jose.readthedocs.io/>
 
-<img src="nbde.png" width="50%" alt="Release Versioning Example">
+- LUKS - is Linux Unified Key Setup and in Version 2 the default Linux Disk Encryption
+
+- NBDE - in detailed overview and boot procedure
+
+![Release Versioning Example](nbde.png)
diff --git a/docs/scs-docs/Design-Docs/terms_and_roles_identity_and_access_management.md b/docs/scs-docs/Design-Docs/terms_and_roles_identity_and_access_management.md
@@ -2,15 +2,15 @@
 
 The objective of this document is to define a basic set of roles and their identifiers / names in SCS. These roles can be used in the Identity and Access Management (IAM) of SCS itself and / or in services provided based on SCS. As Roles are often derived from Usecases which are derived from terms used in a project, the document starts with a definition of terms used in SCS and/or GAIA-X. These definitions should be moved into a separate document in the future.
 
-# Principles used to create this document
+## Principles used to create this document
 
 Where possible the roles and names are derived from existing definitions or conventions used in the underlying software. As SCS is part of GAIA-X, the terms/definitions of GAIA-X are taken as a baseline and will be extended with additional roles needed in SCS. For reference, the current state of relevant GAIA-X definitions can be found at the end of this document.
 
-# SCS terms and their definition
+## SCS terms and their definition
 
 These terms were defined taking into account the GAIA-X definitions to ensure that the same terms are shared.
 
-term               | definition 
+term               | definition
 -------------------|---------------
 Provider           | Legal entity providing SCS to customers. The Provider is typically in control of physical infrastructure (Datacenter, Hosts, Storage, Network etc.) but also employs people who deploy and operate SCS.
 Consumer           | Legal entity which can access and/or consume services hosted on SCS. Typically a Consumer is a customer of a Provider.
@@ -24,23 +24,25 @@ Host               | A Host is a physical machine which is part of a Node. A Nod
 Node               | A Node is a deployment of SCS which offers Services for Customers and/or Endusers. A Node typically is a group of physical Hosts.
 Operator           | Person operating parts of SCS. Each Person is represented by an Identity. Access rights needed to operate are given by assigning an Identity to a Role.
 
-# SCS modules / components
+## SCS modules / components
 
 A module or component of SCS typically is a software stack deployed with a dedicated usecase. This list needs to be elaborated over time.
 
 **this is a best guess example and needs review**
 
 module                 | description
 -----------------------|--------------------------
-OpenStack_<submodule>  | TBD
-Kubernetes_<submodule> | TBD
+OpenStack_```<submodule>```  | TBD
+Kubernetes_```<submodule>``` | TBD
 *to be continued*      |
 
-# SCS Roles
+## SCS Roles
 
 Set of Roles which are initially part of SCS.
 
+```xml
 A Role should be defined as "<Module>_<Usecase>", where "<Module>" is the main module this role applies to and "<Usecase>" a short term to give context which kind of rights / options are given to an identity as member of this role.
+```
 
 **this is a best guess example and needs review**
 
@@ -56,9 +58,7 @@ Kubernetes_Operator   | TBD
 Kubernetes_Customer   | TBD
 *to be continued*      |
 
-
-
-# Current definitions of GAIA-X
+## Current definitions of GAIA-X
 
 This is an excerpt if terms defined in the GAIA-X project. The definitions are work in progress and might change, so this document might be outdated.
 
