Merge branch 'main' into 526-refine-cve-check-in-scs-0210-v2-test-script

.github/scs-compliance-check/openstack/clouds.yaml

@@ -89,6 +89,14 @@ clouds:
     auth:
       auth_url: https://identity.l1a.cloudandheat.com/v3
       application_credential_id: "7ab4e3339ea04255bc131868974cfe63"
+  scaleup-occ2:
+    auth_type: v3applicationcredential
+    auth:
+      auth_url: https://keystone.occ2.scaleup.cloud
+      application_credential_id: "5d2eea4e8bf8448092490b4190d4430a"
+    region_name: "RegionOne"
+    interface: "public"
+    identity_api_version: 3
   syseleven-dus2:
     interface: public
     identity_api_verion: 3

.github/workflows/check-scaleup-occ2-v4.yml

@@ -0,0 +1,23 @@
+name: "Compliance IaaS v4 of scaleup-occ2"
+
+on:
+  # Trigger compliance check every day at 4:30 UTC
+  schedule:
+    - cron:  '30 4 * * *'
+  # Trigger compliance check after Docker image has been built
+  workflow_run:
+    workflows: [Build and publish scs-compliance-check Docker image]
+    types:
+      - completed
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+jobs:
+  check-scaleup-occ2:
+    uses: ./.github/workflows/scs-compliance-check-with-application-credential.yml
+    with:
+      version: v4
+      layer: iaas
+      cloud: scaleup-occ2
+      secret_name: OS_PASSWORD_SCALEUP_OCC2
+    secrets: inherit

.gitignore

@@ -1,6 +1,7 @@
 **/__pycache__/
 .venv/
 .idea
+.sandbox
 .DS_Store
 node_modules
 Tests/kaas/results/

.zuul.d/secure.yaml

@@ -233,6 +233,28 @@
           VCsXjf0qBBMrzz6HP9z95Bk44fiJ3L/LkA3Iij961dYrQXbZKDrKOiX/QPwrcSrVmjmew
           UbPexJFHgvTCqjadoLejSt9cUd9lVzhuzLJ8CS+CcCMbZOno6qathrd2B88riQaPNIGNu
           gfkNT9R63ZzKB1qIA2n5RZi7SH9DPIUd0AwLMn2bhp3uok5pNAPP/4/1RkQiCA=
+      scaleup_occ2_ac_id: !encrypted/pkcs1-oaep
+        - N2duwkcMdOXw6wF0deE/0BPM1M/URt3eWmrnBJ89VHeCDENGfTfDHcWPYs3wW4rSRCG6t
+          gqgNuA049OvOhL7rtjNHZ6yIj6xEHH/YdqT4UxjXPS9GFwoJXDtE8rIGjK3KU8GfUgKnG
+          DLplyyzGzx5j39rJAS628InmC56aip47rO1J4HQE9Ku25Wb06R7ykx+0ZOWr0HXjV/VsV
+          uwfyL+DPgewbL+4u8/XkcI0FwAM9/KkF/CcYUq5aVMdQS2foatTQW0C2idg+pffSTRaau
+          VF44rkVfzsCOz4MYAFpLIaL9Zxx1FifaPOd0oi6rEFjGd6vFtFCHk1BRpKmOITLyx3Te5
+          zVffSkQAsqpn/4er8800bjQzxXvqmQmR0QwPM7dhvRnrNbTSCA/Awm5BPaUgeCZFN3MPN
+          Mc0XIaEwjuJvDK6fqj5tJrVIs5bxAmqRDj8d76AlJcOdDxHicTHgR3aUG4AKOWkUsskgQ
+          3xR8lPh31O/HgzG9tq6o/DCPA1O9wyyOyT7KwJAaRASPCA1O80ZAzhZUNUVyut6dYEwaS
+          QXP4IaEJOxP8EkxR7FDEuO99UFZ7TXQ1CF7ots4wIs5tEpQvcdLnvBjJckp0fNBFTuGMm
+          FCvhgBK30NC93U4DxQv6xZBhqtvHYjHcTOXvz2fryRJT2teMN+eI+RDdV1Jj8Y=
+      scaleup_occ2_ac_secret: !encrypted/pkcs1-oaep
+        - LfUHhslK41JDp3CpslWGGA4bZ3udZh4KnytcXohkdbchb8QVt8eNc4nD0ti0/XS18YKwq
+          DlHOWw2rDJZ8RGIXENVUYzDbECoBErE8IAqQE0q3oS/8Oq0NYOFTGvvlKuue7U4s87Pwi
+          YFi+Q0Rv7vO8cWFVtbRHK+Hw6pC42Biq2T+tuVBCLqylIMViXpuEy9UpFLEv59zr6EHa9
+          uB3xkjnpWuabe7vrG+LQHc0pJ5tNhcLiOnJggU5Ef02FBy+t6xvuJW8f6cXCnRRj1q0fl
+          D/vTmC7avwHnWC+J4WLL69HCwW05I7iHftVSWOXQgRzMBd4D4ND2OXfsWElu0eOV5XG6X
+          JsQH8lDnVN/lqaDAOYR4fk4+9yt3RURwvNL5FUnDK1t7LAI4X0gcvLrQAfzgOlpBYDXSK
+          0kbUzqwivuw1v2zO/gxQU+J28PsOfZaKf/7ZZyj3e/tiq4wBpvPb0mVBwWXigKqzr+QED
+          Iy2u/g3x2qdcTpXR/RPq+xiXM2B2rw1V5gdkscdL+avXtTF7hT9HrcayHx3HDZ/h6aGPD
+          RWIJ8bstl+x2Q4zExgR13amWM8ZR1iLGCN20U/ZAaqANCqjDbrSVSTjTPzYtNFwAXwxkB
+          3NHhPDHZ1MIdr6IJE4IZ4TCMsIeTA2UHNfF4RCzeDSIJ+CXOQxUFWOxZkf97WY=
       syseleven_dus2_ac_id: !encrypted/pkcs1-oaep
         - SjwtIvJO7DkLJDmS+T/Z5utFBa22hmPRBd8mzonJHGgURB2W7fmXFreD9NPrLfbt7ujKi
           KNqJm8k1Vr1F3Mu+Osr0BWSnq5makwVt2ikBY4qPbL8iyVXsByaT/HNPLCOokqy+REpfu

Standards/scs-0102-v1-image-metadata.md

@@ -1,5 +1,5 @@
 ---
-title: SCS Image Metadata Standard
+title: SCS Image Metadata
 type: Standard
 stabilized_at: 2022-10-31
 status: Stable

Standards/scs-0114-v1-volume-type-standard.md

@@ -1,8 +1,9 @@
 ---
-title: Volume Type Standard
+title: SCS Volume Types
 type: Standard
-status: Draft
-track:  IaaS
+status: Stable
+stabilized_at: 2024-11-13
+track: IaaS
 ---
 
 ## Introduction

Standards/scs-0115-v1-default-rules-for-security-groups.md

@@ -1,7 +1,8 @@
 ---
 title: Default Rules for Security Groups
 type: Standard
-status: Draft
+status: Stable
+stabilized_at: 2024-11-13
 track: IaaS
 ---
 
@@ -25,7 +26,7 @@ Administrator (abbr. Admin)
 
 ### Default Security Groups, Custom Security Groups and default Security Group Rules
 
-To properly understand the concepts in this standard and avoid ambiguity, is very important to distinguish between the following similar-sounding but different resources in the OpenStack Networking API:
+To properly understand the concepts in this standard and avoid ambiguity, it is very important to distinguish between the following similar-sounding but different resources in the OpenStack Networking API:
 
 1. default Security Group
 2. custom Security Group
@@ -59,10 +60,10 @@ Therefore, this standard proposes default Security Group rules that MUST be set
 
 ## Design Considerations
 
-Up to the 2023.1 release (antelope) the default Security Group rules are hardcoded in the OpenStack code.
-We should not require to change this behavior through code changes in deployments.
+Up to the 2023.1 release (Antelope) the default Security Group rules are defined in the OpenStack code.
+We should not require changing this behavior through code changes in deployments.
 
-Beginning with the 2023.2 release (bobcat) the default Security Group rules can now be edited by administrators through an API.
+Beginning with the 2023.2 release (Bobcat) the default Security Group rules can now be edited by administrators through an API.
 All rules that should be present as default in Security Groups have to be configured by admins through this API.
 
 There are two ways to approach a standard for the default rules of Security Groups.

Standards/scs-0116-v1-key-manager-standard.md

@@ -1,7 +1,8 @@
 ---
-title: Key Manager Standard
+title: SCS Key Manager Standard
 type: Standard
-status: Draft
+status: Stable
+stabilized_at: 2024-11-13
 track: IaaS
 ---
 

Standards/scs-0116-w1-key-manager-implementation-testing.md

@@ -44,6 +44,11 @@ This can be done with a small change in the policy.yaml file. The `creator` has
 The check for the presence of a Key Manager is done with a test script, that checks the presence of a Key Manager service in the catalog endpoint of Openstack.
 This check can eventually be moved to the checks for the mandatory an supported service/API list, in case of a promotion of the Key Manager to the mandatory list.
 
+### Implementation
+
+The script [`check-for-key-manager.py`](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/key-manager/check-for-key-manager.py)
+connects to OpenStack and performs the checks described in this section.
+
 ## Manual Tests
 
 It is not possible to check a deployment for a correctly protected Master KEK automatically from the outside.

Standards/scs-0117-v1-volume-backup-service.md

@@ -1,7 +1,8 @@
 ---
 title: Volume Backup Functionality
 type: Standard
-status: Draft
+status: Stable
+stabilized_at: 2024-11-13
 track: IaaS
 ---
 

Standards/scs-0118-v1-taxonomy-of-failsafe-levels.md

@@ -1,5 +1,5 @@
 ---
-title: Taxonomy of Failsafe Levels
+title: SCS Taxonomy of Failsafe Levels
 type: Decision Record
 status: Draft
 track: IaaS

Standards/scs-0121-v1-Availability-Zones-Standard.md

@@ -1,7 +1,8 @@
 ---
-title: Availability Zones Standard
+title: SCS Availability Zones
 type: Standard
-status: Draft
+status: Stable
+stabilized_at: 2024-11-13
 track: IaaS
 ---
 

Standards/scs-0121-w1-Availability-Zones-Standard.md

@@ -1,5 +1,5 @@
 ---
-title: "SCS Availability Zone Standard: Implementation and Testing Notes"
+title: "SCS Availability Zones: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
 status: Draft

Drafts/node-to-node-encryption.md → Standards/scs-0122-v1-node-to-node-encryption.md

@@ -1,7 +1,7 @@
 ---
 title: _End-to-End Encryption between Customer Workloads_
 type: Decision Record
-status: Proposal
+status: Draft
 track: IaaS
 ---
 

Standards/scs-0123-v1-mandatory-and-supported-IaaS-services.md

@@ -0,0 +1,82 @@
+---
+title: Mandatory and Supported IaaS Services
+type: Standard
+status: Draft
+track: IaaS
+---
+
+## Introduction
+
+To be SCS-compliant a Cloud Service Provider (CSP) has to fulfill all SCS standards.
+Some of those standards are broad and consider all APIs of all services on the IaaS-Layer like the consideration of a [role standard](https://github.com/SovereignCloudStack/issues/issues/396).
+There exist many services on that layer and for a first step they need to be limited to have a clear scope for the standards and the Cloud Service Providers following them.
+For this purpose, this standard will establish lists for mandatory services whose APIs have to be present in a SCS cloud as well as supported services, which APIs are considered by some standards and may even be tested for their integration but are optional in a sense that their omission will not violate SCS conformance.
+
+## Motivation
+
+There are many OpenStack APIs and their corresponding services that can be deployed on the IaaS level.
+These services have differences in the quality of their implementation and liveness and some of them may be easily omitted when creating an IaaS deployment.
+To fulfill all SCS-provided standards only a subset of these APIs are required.
+Some more but not all remaining OpenStack APIs are also supported additionally by the SCS project and may be part of its reference implementation.
+This results in different levels of support for specific services.
+This document will give readers insight about how the SCS classifies the OpenStack APIs accordingly.
+If a cloud provides all mandatory and any number of supported OpenStack APIs, it can be tested for SCS-compliance.
+Any unsupported APIs will not be tested.
+
+## Mandatory IaaS APIs
+
+The following IaaS APIs MUST be present in SCS-compliant IaaS deployments and could be implemented with the corresponding OpenStack services:
+
+| Mandatory API | corresponding OpenStack Service | description |
+|-----|-----|-----|
+| **block-storage** | Cinder | Block Storage service |
+| **compute** | Nova | Compute service |
+| **identity** | Keystone | Identity service |
+| **image** | Glance | Image service |
+| **load-balancer** | Octavia | Load-balancer service |
+| **network** | Neutron | Networking service |
+| **s3** | S3 API object storage | Object Storage service |
+
+:::caution
+
+S3 API implementations may differ in certain offered features.
+CSPs must publicly describe, which implementation they use in their deployment.
+Users should always research whether a needed feature is supported in the offered implementation.
+
+:::
+
+The endpoints of services MUST be findable through the `catalog list` of the identity API[^1].
+
+[^1]: [Integrate into the service catalog of Keystone](https://docs.openstack.org/keystone/latest/contributor/service-catalog.html)
+
+## Supported IaaS APIs
+
+The following IaaS APIs MAY be present in SCS-compliant IaaS deployment, e.g. implemented thorugh the corresponding OpenStack services, and are considered in the SCS standards.
+
+| Supported API | corresponding OpenStack Service | description |
+|-----|-----|-----|
+| **bare-metal** | Ironic | Bare Metal provisioning service |
+| **billing** | Cloudkitty | Rating/Billing service |
+| **dns** | Designate | DNS service |
+| **ha** | Masakari | Instances High Availability service |
+| **key-manager** | Barbican | Key Manager service |
+| **object-store** | Swift | Object Store with different possible backends |
+| **orchestration** | Heat | Orchestration service |
+| **shared-file-systems** | Manila | Shared File Systems service |
+| **telemetry** | Ceilometer | Telemetry service |
+| **time-series-databse** | Gnocchi | Time Series Database service |
+
+## Unsupported IaaS APIs
+
+All other OpenStack services, whose APIs are not mentioned in the mandatory or supported lists will not be tested for their compatibility and conformance in SCS clouds by the SCS community.
+Those services MAY be integrated into IaaS deployments by a Cloud Service Provider on their own responsibility but the SCS will not assume they are present and potential issues that occur during deployment or usage have to be handled by the CSP on their own accord.
+The SCS standard offers no guarantees for compatibility or reliability of services categorized as unsupported.
+
+## Related Documents
+
+[The OpenStack Services](https://www.openstack.org/software/)
+
+## Conformance Tests
+
+The presence of the mandatory OpenStack APIs will be tested in [this test-script](https://github.com/SovereignCloudStack/standards/blob/mandatory-and-supported-IaaS-services/Tests/iaas/mandatory-services/mandatory-iaas-services.py).
+The test will further check, whether the object store endpoint is compatible to s3.