Feat/add certification process2

sidebarsStandards.js

@@ -7,9 +7,10 @@ const sidebars = {
       label: 'Certification',
       link: {
         type: 'doc',
-        id: 'certification/overview'
+        id: 'certification/cert-levels'
       },
       items: [
+        'certification/digisov-and-cert',
         {
           type: 'category',
           label: 'Scopes and Versions',
@@ -18,7 +19,9 @@ const sidebars = {
             id: 'certification/scopes-versions'
           },
           items: require('./sidebarsCertificationItems.js') // this file will be generated entirely by `populateCerts.js` via npm post-install hook found in the package.json
-        }
+        },
+        'certification/getting-scs-compatible-certified',
+        'certification/overview'
       ]
     },
     {

standards/certification/cert-levels.md

@@ -0,0 +1,44 @@
+# SCS certification overview
+
+## Digital sovereignty drives SCS certification
+
+The SCS project takes a comprehensive perspective on digital sovereignty.
+Please read [Digital Sovereignty and SCS certification](digisov-and-cert)
+for more details.
+
+The basic level, control over data that at least allows to comply with the
+European GDPR regulation, is *not* certified by SCS; while the SCS software
+makes it easy to build (local) clouds that fulfill these, it depends on the
+operators of the infrastructure what compliance rules they fulfill.
+
+The SCS project however has defined certification levels for levels two,
+three and four in the sovereignty taxonomy.
+
+| Digital Sovereignty level         | SCS certification         |
+|-----------------------------------|---------------------------|
+| 1: Data Sov'ty / Legal compliance | (Refer to ENISA/Gaia-X)   |
+| 2: Provider switching / Tech Compatiiblity | *SCS-compatible* |
+| 3: Ability to shape technology    | *SCS-open*                |
+| 4: Transparency & SKills for Operations    | *SCS-sovereign*  |
+
+As of September 2024, the *SCS-compatible* certification level is defined
+and used; the details for the higher levels are still being worked on.
+
+## Certification process
+
+To get certified, the infrastructure needs to fulfill certain criteria.
+As far as possible, these are implemented as automated tests that run
+continuously (daily) to assure continuous compliance. The results are
+made transparent via the the [Certified Clouds overview](overview) page.
+
+To get officially certified with the right to use the SCS brand and getting
+listed on this page requires to work with the Forum SCS-Standards at the
+[OSB Alliance](https://osb-alliance.com/) which takes over this aspect
+from the [SCS project](https://scs.community/). It requires membership
+or certification fees to cover the efforts of standardization and
+certification.
+
+The process is described in more details on the
+[Getting SCS-compatible certification (for Operators)](getting-scs-compatible-certified)
+page. An example with technical testing and adjustments is on the
+[Testing and Adjustment example](test-and-adapt-example) page.

standards/certification/digisov-and-cert.md

@@ -0,0 +1,120 @@
+# Digital Sovereignty and SCS certification
+
+## The taxonomy of digital sovereignty
+
+As published in [DuD](https://rdcu.be/cWdBJ) (German, English version in
+[the cloud report](https://the-report.cloud/why-digital-sovereignty-is-more-than-mere-legal-compliance/))
+and being summarized nicely in a [cloudahead article](https://www.cloudahead.de/der-freiheitskampf-des-sovereign-cloud-stacks),
+we differentiate between several levels of digital sovereignty.
+Level 0 (introduced by Gregor Schuhmacher in the cloudahead article)
+which describes having real clouds (see
+[NIST definition of cloud](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf))
+with self-service on-demand API driven service shall be taken for granted.
+
+The levels as seen by the SCS project are:
+
+1. Control over data and data sharing and ability to fulfill regulatory requirements
+   (e.g. GDPR) around data control.
+2. Capability to chose between *highly compatible* operators, this way enabling a provider
+   switch or using several providers in a federated fashion. This also includes the
+   possibility to run your own infrastructure in a *highly compatible* manner.
+3. Capability to influence and shape the infrastructure, enabling innovation at the
+   infrastructure layer.
+4. Transparency over operational aspects of running infrastructure, this way supporting
+   to overcome a skill gap to being able to operate infrastructure in a highly reliable
+   manner.
+
+These aspects of sovereignty drive the work from the SCS team.
+
+Level number 1 is sometimes referred to as "data sovereignty". Achieving it does require
+cloud infrastructure and cloud operations that can not be interfered with by actors that
+in ways incompatible with the respective jurisdiction. For Europeans that need to observe GDPR,
+this excludes using US clouds for personally identifiable information, expecting that the
+adequacy decisions for the US do not fully address the risks. The SCS project does not
+have deep legal expertise and refers to the work from [noyb](https://noyb.eu/)
+and [ENISA](https://www.enisa.europa.eu/) here.
+
+In order to achieve level 2,
+the SCS community has worked on standards that define the APIs and the infrastructure
+behavior, so application developers and application operators can deploy the same application
+using the same automation and rely on the same infrastructure behavior to operate the
+application in a resilient way. The standards allow for switching providers or to use
+several providers in a federated way. Operating own infrastructure according to the same
+standards is also possible, allowing for hybrid cloud setups without technical barriers.
+
+Level 3 drives the work on a comprehensive openly developed open source software stack,
+allowing operators to use, study, change and redistribute the software according to the
+[Four Freedoms](https://en.wikipedia.org/wiki/The_Free_Software_Definition) of free software. We are requiring
+a complete stack that uses [OSI](https://opensource.org/)-approved open source licenses
+as to ensure that users have the four freedoms, the right to use, study, modify, (re)distribute
+the software that drives the cloud stack. To ensure that this does not require extensive
+and expensive forking, we further require the [Four Opens](https://openinfra.dev/four-opens/)
+of the Open Infra Foundation here. The software can be used to provide cloud services
+for others (public cloud) or just for your own community (community cloud) or
+internal (private cloud) needs.
+
+Level 4 addresses the skills and transparency aspects. Operating highly dynamic distributed
+systems in a reliable manner requires knowledge and experience — engineers with these skills
+are scarce. To address this, the SCS team networks operations staff from providers and helps
+to share and distill common knowledge that help everyone to be more successful. SCS has
+thus been driving the [Open Operations](https://openoperations.org) initiative.
+
+Levels 2 and 3 are sometimes related to the term "technological sovereignty",
+indicating the ability to control and shape the technology.
+
+## The SCS certification levels
+
+Corresponding to the levels of digital sovereignty in the SCS taxonomy, SCS defines
+SCS certification levels
+
+1. (Defined outside of the SCS scope)
+2. *SCS-compatible*
+3. *SCS-open*
+4. *SCS-sovereign*
+
+### Why no SCS certification for GDPR?
+
+SCS significantly lowers the bar to offer real cloud services. These can be used internally
+(private cloud) or to offer services for your community, your region or country. The vision
+is to have a network of providers. We expect most if not all of them to be operated in ways
+that fulfill the European GDPR regulation; it is also possible to operate clouds that fulfill
+special regulation, e.g. in the banking or insurance sector.
+
+SCS is not in a position to judge this and thus defines no own label / certificate to
+vouch for regulatory compliance. We typically refer to the
+[ENISA](https://www.enisa.europa.eu/) for GDPR considerations
+and also recommend to take the [Gaia-X](https://gaia-x.eu/) labels into account here.
+
+## Status of SCS certification for cloud operators
+
+As of September 2024, the requirements for *SCS-open* and *SCS-sovereign*
+certification have not been formalized yet.
+
+The technical compatibility validation corresponding to the *SCS-compatible* certification does
+exist since more than a year. There are certificates for two layers of the SCS architecture
+stack:
+
+* The virtualization layer: *SCS-compatible IaaS*
+* The container layer: *SCS-compatible KaaS*
+
+For each of these, technical tests are being run to test service offerings for compliance.
+The standards and the corresponding tests are versioned. The *SCS-compatible* certification
+for a specific layer (currently IaaS or KaaS) and version is called a *certification scope*.
+Please see [Scopes and Versions](scopes-versions.md) for detailed definitions.
+
+As of September 2024, the latest SCS-compatible certification scope on the IaaS layer is
+SCS-compatible IaaS v4. For November 2024, SCS-compatible IaaS v5 and the first Kaas
+scope SCS-compatible KaaS v1 are planned.
+
+## Certification for non-operators
+
+Software can deliver infrastructure components for operators to provide SCS-compatible
+IaaS or KaaS; it is planned that infrastructure software can also receive SCS certification.
+
+Likewise, applications can be developed in a way that they will work without any changes on
+all SCS-compatible IaaS or on all SCS-compatible KaaS (or may require both). It is planned
+that such software can also be certified.
+
+Implementation partners from the SCS ecosystem may support operators (CSPs) to build
+and operate SCS-compatible infrastructure. A certification program that certifies the
+skills and experience of such partners is planned as well.

standards/certification/getting-scs-compatible-certified.md

@@ -0,0 +1,13 @@
+# Getting SCS-compatible certification
+
+The conditions to become *SCS-compatible* certified are defined in the
+[SCS standard 0004](/standards/scs-0004-v1-achieving-certification).
+
+Hints how the process is working in practice for existing certified
+clouds can be found in the corresponding
+[Implementation Notes](standards/scs-0004-w1-achieving-certification-implementation).
+
+There is a [blog article with an example](https://scs.community/blog/2024/10/14/cert-adapt-example)
+of running the test suite and addressing the failures. Observations on
+[making an OpenStack cloud that is not using the SCS reference implementation compliant](https://scs.community/2024/05/13/cost-of-making-an-openstack-cluster-scs-compliant/)
+are covered in another blog article.

standards/certification/overview.template.md

@@ -1,13 +1,5 @@
+# Compliant clouds overview
 <!-- markdownlint-disable -->
-# Certification
-
-SCS certificates come with various scopes. See [Scopes and Versions](scopes-versions.md) for details.
-
-## Becoming certified
-
-In order for a cloud service offering to obtain a certificate, it has to conform to all standards of the respective scope, which will be tested at regular intervals, and the results of these tests will be made available publicly. For more details on how to become certified, please consult the corresponding [document](/standards/scs-0004-v1-achieving-certification).
-
-## Compliant cloud environments
 
 This is a list of clouds that we test on a nightly basis against the certificate scope _SCS-compatible IaaS_.