Merge branch 'main' into issue/662_default_storage_class

fraugabel · web-flow · commit 6e5754ef389d · 2024-11-18T17:58:28.000+01:00
diff --git a/Standards/scs-0100-w1-flavor-naming-implementation-testing.md b/Standards/scs-0100-w1-flavor-naming-implementation-testing.md
@@ -2,7 +2,7 @@
 title: "SCS Flavor Naming Standard: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0100-v1-flavor-naming.md
   - scs-0100-v2-flavor-naming.md
diff --git a/Standards/scs-0101-w1-entropy-implementation-testing.md b/Standards/scs-0101-w1-entropy-implementation-testing.md
@@ -2,7 +2,7 @@
 title: "SCS Entropy: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0101-v1-entropy.md
 ---
diff --git a/Standards/scs-0102-w1-image-metadata-implementation-testing.md b/Standards/scs-0102-w1-image-metadata-implementation-testing.md
@@ -2,7 +2,7 @@
 title: "SCS Image Metadata: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0102-v1-image-metadata.md
 ---
diff --git a/Standards/scs-0104-w1-standard-images-implementation.md b/Standards/scs-0104-w1-standard-images-implementation.md
@@ -2,7 +2,7 @@
 title: "SCS Standard Images: Implementation Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0104-v1-standard-images.md
 ---
diff --git a/Standards/scs-0114-v1-volume-type-standard.md b/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
diff --git a/Standards/scs-0115-v1-default-rules-for-security-groups.md b/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
 ---
 
diff --git a/Standards/scs-0116-v1-key-manager-standard.md b/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
 ---
 
diff --git a/Standards/scs-0116-w1-key-manager-implementation-testing.md b/Standards/scs-0116-w1-key-manager-implementation-testing.md
@@ -2,7 +2,7 @@
 title: "SCS Key Manager Standard: Implementation and Testing Notes"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0116-v1-key-manager-standard.md
 ---
diff --git a/Standards/scs-0117-v1-volume-backup-service.md b/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
 ---
 
diff --git a/Standards/scs-0118-w1-example-impacts-of-failure-scenarios.md b/Standards/scs-0118-w1-example-impacts-of-failure-scenarios.md
@@ -2,7 +2,7 @@
 title: "SCS Taxonomy of Failsafe Levels: Examples of Failure Cases and their impact on IaaS and KaaS resources"
 type: Supplement
 track: IaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0118-v1-taxonomy-of-failsafe-levels.md
 ---
diff --git a/Standards/scs-0121-v1-Availability-Zones-Standard.md b/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
 ---
 
diff --git a/Standards/scs-0121-w1-Availability-Zones-Standard.md b/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
diff --git a/Standards/scs-0122-v1-node-to-node-encryption.md b/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
 ---
 
diff --git a/Standards/scs-0123-v1-mandatory-and-supported-IaaS-services.md b/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-database** | 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.
diff --git a/Standards/scs-0211-w1-kaas-default-storage-class-implementation-testing.md b/Standards/scs-0211-w1-kaas-default-storage-class-implementation-testing.md
@@ -2,7 +2,7 @@
 title: "SCS KaaS default storage class: Implementation and Testing Notes"
 type: Supplement
 track: KaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0211-v1-kaas-default-storage-class.md
 ---
diff --git a/Standards/scs-0214-w1-k8s-node-distribution-implementation-testing.md b/Standards/scs-0214-w1-k8s-node-distribution-implementation-testing.md
@@ -2,7 +2,7 @@
 title: "Kubernetes Node Distribution and Availability: Implementation and Testing Notes"
 type: Supplement
 track: KaaS
-status: Proposal
+status: Draft
 supplements:
   - scs-0214-v1-k8s-node-distribution.md
   - scs-0214-v2-k8s-node-distribution.md
diff --git a/Standards/scs-0219-v1-kaas-networking.md b/Standards/scs-0219-v1-kaas-networking.md
@@ -0,0 +1,99 @@
+---
+title: KaaS Networking Standard
+type: Standard
+status: Draft
+track: KaaS
+---
+
+## Introduction
+
+Kubernetes defines a networking model that needs to be implemented by a separate CNI plugin.
+Beyond basic connectivity within the cluster, however, there are many networking features that are specified but optional.
+Some of these optional features provide vital functionality, such as the NetworkPolicy API and the Ingress API.
+
+This standard specifies a minimal set of networking features that users can expect in clusters created by an SCS-compliant KaaS provider.
+
+## Terminology
+
+The following terms are used throughout this document:
+
+| Term | Meaning |
+|------|---------|
+| KaaS, managed Kubernetes | Kubernetes as a Service, automated on-demand deployment of Kubernetes clusters. |
+| CSP | Cloud Service Provider, the provider of the KaaS infrastructure. |
+| CNI | Container Network Interface, a standardized networking interface for container runtimes. |
+| CNI plugin, networking plugin | Kubernetes bindings for a CNI implementation, translates Kubernetes API concepts into more basic container networking concepts. |
+| network policy | A set of rules to restrict network traffic in a Kubernetes cluster. |
+
+## Motivation
+
+KaaS providers will typically support aditional networking functionality beyond basic Kubernetes networking.
+The specific range of features depends on the used CNI plugin, but may also be extended by additional operators.
+Users may expect certain optional functionality, so we should define a baseline feature set that has to be available in an SCS-compliant KaaS cluster.
+
+## Design Considerations
+
+The Kubernetes API can be extended arbitrarily.
+Many CNI plugins will define custom resources to enable functionality that is not covered in the official [API specification](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/).
+Sometimes they will even reuse names from different API groups, such as `NetworkPolicy`, which exists in the basic `networking.k8s.io/v1` API, but also in `projectcalico.org/v3`.
+
+To avoid any ambiguity, we should therefore be explicit about the API groups and versions of resources.
+We should also avoid mandating third-party API extensions, to avoid dependencies on specific third-party software and keep the standard as generic as possible.
+
+### Options considered
+
+#### NetworkPolicy API
+
+Kubernetes network policies are used to restrict network traffic between pods in a cluster, but also between pods and external network resources.
+The policy rules can filter based on port and address ranges, but also on Kubernetes-specific target attributes such as namespaces and labels.
+They must be implemented by the CNI plugin, and though they are widely supported, they are still technically optional, and there are some lightweight networking plugins, such as Flannel, that are not enforcing them.
+
+Nonetheless, network policies are widely used and most users will expect them in a managed Kubernetes cluster.
+The wide, but varying support among CNI plugins makes them a good target for SCS standardization.
+
+#### Default Network Policies in Namespaces
+
+Basic network policies are namespaced resources, and can only filter traffic to and from pods in their own namespace.
+In a newly created namespace without policies the default behavior will apply, which is to not restrict traffic at all.
+
+It can be desirable to automatically create default network policies in new namespaces, using a policy operator such as Kyverno.
+A CSP could provide such an operator and offer a number of default policies, like blocking connections to other namespaces by default, or blocking access to the OpenStack metadata service.
+
+Any user with permissions to manage their own network policies in a namespace will of course be able to remove or modify any default network policies in that namespace.
+CSP-provided network policies should thus only be viewed as a safety default, and should only be deployed if they are actually beneficial to users.
+
+#### AdminNetworkPolicy API
+
+An alternative to automatically created default network policies are API extensions that allow cluster-wide networking rules.
+Some CNI plugins have implemented such extensions, e.g. Calico's `GlobalNetworkPolicy` and Cilium's `CiliumClusterwideNetworkPolicy`.
+
+The Kubernetes Network Special Interest Group is currently working on an [official API extension](https://network-policy-api.sigs.k8s.io/api-overview/) to cover this functionality.
+This API extension introduces the new `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` resources, which represent cluster-wide network policies with respectively higher or lower precedence than namespaced network policies.
+
+This API is also a good candidate for standardization because it consolidates a number of vendor-specific workarounds to limitations of the NetworkPolicy API.
+It has not been stabilized yet, so currently we can at most recommend CNI plugins where there is ongoing work to support these features.
+
+#### Ingress API
+
+The Ingress API allows the external exposure of HTTP/HTTPS-based services running in the cluster.
+Unlike the L3/L4-based LoadBalancer Service type, Ingress provides L7 load balancing, HTTP routing, and TLS termination for services.
+This functionality can be provided within the cluster by a pod-based ingress controller such as `ingress-nginx`, that exposes Ingress resources as Services.
+
+However, there are also Ingress controllers that integrate with underlying infrastructure and may help to reduce overhead.
+Examples for this are the Cilium CNI plugin, which comes with built-in Ingress support, and the Octavia Ingress controller, which may be a good choice if OpenStack Octavia is already used to provide L3/L4 load balancing.
+
+The CSPs that manage the underlying infrastructure can of course make the best choice for such an integrated Ingress controller, so they should be encouraged to do so.
+Even with a CSP-provided default Ingress controller present, users will be able to use alternative Ingress controllers by creating a new `IngressClass`, which can then be referenced in Ingress resources.
+
+## Decision
+
+CSPs MUST provide a network plugin that fully supports `NetworkPolicy` resources in the API version `networking.k8s.io/v1`.
+CSPs SHOULD provide a network plugin that supports or is working on support for the `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` resources of the `policy.networking.k8s.io` API group, in their latest version, up to `v1`.
+
+CSPs SHOULD offer the option for a managed, `networking.k8s.io/v1`-compliant Ingress controller and a default `IngressClass` resource for this controller.
+
+CSPs MAY add default networking restrictions, using either `networking.k8s.io/v1`-compliant `NetworkPolicy` resources with a policy operator, or alternatively any cluster-wide network policy extensions provided by the CNI plugin.
+
+## Conformance Tests
+
+Required support for network policies will be tested using the upstream e2e tests via Sonobuoy.
diff --git a/Standards/scs-0219-w1-kaas-networking.md b/Standards/scs-0219-w1-kaas-networking.md
@@ -0,0 +1,27 @@
+---
+title: "KaaS Networking Standard: Implementation Notes"
+type: Supplement
+track: KaaS
+status: Draft
+supplements:
+  - scs-0219-v1-kaas-networking.md
+---
+## List of compliant CNI Plugins
+
+The Kubernetes Network Policy API working group maintains a [list of work-in-progress implementations](https://network-policy-api.sigs.k8s.io/implementations/) of the AdminNetworkPolicy and BaselineAdminNetworkPolicy resources.
+Besides their own proof-of-concept implementation of [kube-network-policies](https://github.com/kubernetes-sigs/kube-network-policies), at the time of writing they list the following CNI plugins:
+
+- [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)
+- [Antrea](https://github.com/antrea-io/antrea/)
+- [KubeOVN](https://github.com/kubeovn/kube-ovn)
+- [Calico](https://github.com/projectcalico/calico)
+- [Cilium](https://github.com/cilium/cilium)
+
+All of these plugins also implement the basic NetworkPolicy API, and are therefore compliant both with the standard's requirements and recommendations.
+
+The CNI plugin [Flannel](https://github.com/flannel-io/flannel) does not support network policies by itself, but can be combined with Calico for policy enforcement.
+This configuration is known as [Canal](https://docs.tigera.io/calico/latest/getting-started/kubernetes/flannel/install-for-flannel) and will likely profit from Calico's support for AdminNetworkPolicy.
+
+There are more CNI plugins that support the NetworkPolicy API, but are not known to work on support of the AdminNetworkPolicy extensions.
+As such they are still compliant with the current version of the Standard.
+However, these seem to be either vendor-specific, like the [Azure CNI](https://learn.microsoft.com/de-de/azure/aks/configure-azure-cni), or unmaintained, like [Weave](https://github.com/weaveworks/weave).
diff --git a/Standards/scs-0302-v1-domain-manager-role.md b/Standards/scs-0302-v1-domain-manager-role.md
diff --git a/Standards/scs-0302-w1-domain-manager-implementation-notes.md b/Standards/scs-0302-w1-domain-manager-implementation-notes.md
diff --git a/Standards/scs-XXXX-vN-decision-record-template.md b/Standards/scs-XXXX-vN-decision-record-template.md
diff --git a/Standards/scs-XXXX-vN-standard-template.md b/Standards/scs-XXXX-vN-standard-template.md
diff --git a/Tests/iaas/mandatory-services/README.md b/Tests/iaas/mandatory-services/README.md
diff --git a/Tests/iaas/mandatory-services/mandatory-iaas-services.py b/Tests/iaas/mandatory-services/mandatory-iaas-services.py
diff --git a/Tests/kaas/k8s-version-policy/k8s-eol-data.yml b/Tests/kaas/k8s-version-policy/k8s-eol-data.yml
