Feat/add certification process

sidebarsStandards.js

@@ -6,19 +6,22 @@ const sidebars = {
       type: 'category',
       label: 'Certification',
       link: {
-        type: 'doc',
-        id: 'certification/overview'
+	type: 'doc',
+	id: 'certification/digisov-and-cert'
       },
       items: [
-        {
+	{
           type: 'category',
           label: 'Scopes and Versions',
           link: {
             type: 'doc',
             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/test-and-adapt-example',
+        'certification/overview'
       ]
     },
     {

standards/certification/digisov-and-cert.md

@@ -0,0 +1,121 @@
+# 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.
+We'll skip stage 0, introduced by Gregor Schuhmacher in his description, which
+specifies using a cloud at all as the pre-step to be taken. This has relevance,
+as some companies continue to call solutions that are not on-demand, not
+self-service API driven, not metered
+(see [NIST definition of cloud](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf))
+to be (private) clouds. We talk about real clouds, where deployment of infrastructure
+is API-driven, unlocking DevOps teams productivity.
+
+The levels as seen by the SCS movement are:
+
+1. Control over data and data sharing and ability to fulfill regulatory requirements (GDPR)
+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 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
+are outside of 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 real open source licenses (as defined by [OSI](https://opensource.org/))
+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
+that 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 for GDPR considerations
+and also recommend to take the Gaia-X labels into account here.
+
+## Status of SCS certification for cloud operators
+
+As of September 2024, we have not yet formalized the requirements for SCS-open and SCS-sovereign
+certification.
+
+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,113 @@
+# Getting SCS-compatible certification (for operators)
+
+## Process overview
+
+The SCS Certification is a technical certification:
+The Operator needs to fulfill technical requirements, such as providing certain
+APIs and guaranteeing certain platform behavior in order to be certifiable.
+
+These requirements are meant to provide guarantees to their customers, allowing
+them to rely on certain features to be available and on certain system behavior
+that lets their applications run in a reliable way.
+
+The SCS certification process typically consists of a few simple steps:
+
+1. Running the SCS compliance test suite and adjusting the infrastructure until it passes.
+2. Any additional declarations (for non-testable aspects) are written and passed to the SCS Forum.
+3. The operator must be a member ("shaper" or "advisor" level) of the Forum SCS-Standards in the
+   OSB Alliance (a non-profit) and pay the respective membership fees. Alternatively fees can
+   be paid without becoming a member.
+4. The cloud can be listed on the SCS pages as SCS-compatible with a compatibility status that is
+   updated on a daily basis. SCS then tests the infrastructure on a daily basis.
+
+## Self-testing and technical adjustments
+
+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).
+
+The best approach to get your cloud into compliance is by installing the
+test suite locally. Have a look at the [example](/standards/test-and-adapt-example).
+
+A description how SCS-compatible IaaS compliance can be achieved on environments that use different
+OpenStack implementations is written up in a blog article
+[Cost of making an OpenStack Cluster SCS compliant](https://scs.community/de/2024/05/13/cost-of-making-an-openstack-cluster-scs-compliant/).
+
+## Declarations
+
+For the SCS-compatible IaaS v5 standard, the providers must -- if they implement availability zones
+at all (which is optional) -- guarantee certain levels of independence for these. This can not
+be fully tested by an automated test. The process thus envisions that providers must create some
+documentation on the physical infrastructure and how it maps to availability zones and declare that
+this documentation reflects the truth. SCS will review the docs and judge whether they meet the
+criteria. In case of doubt, audits can be performed.
+
+## Forum SCS-Standards @ OSBA
+
+The SCS brand belongs to the Open Source Business Alliance e.V. (OSBA), an non-profit organization and
+association for the Open Source Industry in Germany. The OSBA creates the Forum SCS-Standards
+which performs the work to evolve the SCS standards, develops the tests and perform the certification
+process.
+
+Members of the OSBA can become also member of the Forum SCS-Standards for an additional membership
+fee, providing the financial resources for the Forum to do its work. Membership in the OSBA is
+open to any organization that supports the goals of the OSBA.
+Alternatively, a certification fee can be paid without any membership; the fee corresponds to the
+lower tier membership fee.
+
+## Getting listed and tested
+
+When all tests are passing, all needed declarations are done, fees for the certification or the
+membership in the Forum SCS-Standards at the OSBA have been paid, the infrastructure service
+can become officially certified. 
+
+The SCS team will add the cloud to the [list of certified clouds](https://docs.scs.community/standards/certification/overview)
+on the SCS docs page. This can be used to prove to customers that the cloud is SCS compliant.
+Note that there will be a nightly job that tests the cloud for compliance, which will be
+triggered by SCS infrastructure (zuul). For this, access to a tenant on the cloud needs
+to be provided free of charge. (This only requires very low quota, one VM is created for a minute
+in one of the tests.)
+The list of certified clouds will be replaced by the
+[compliance monitor](https://compliance.sovereignit.cloud/page/table) soon.
+
+For clouds not being accessible from the outside, a VPN tunnel or a local monitoring
+job (with result upload) can be used.
+
+Next to the addition into the list, we also plan to create an SCS-certified badge that
+operators will be allowed to use in their marketing material as long as they fulfill the
+certification conditions.
+
+Note that for almost all certified clouds in the list of certified clouds, we also
+have a health monitor running (currently still
+[openstack-health-monitor](https://github.com/SovereignCloudStack/openstack-health-monitor/),
+but soon the new [health-monitor](https://scs.community/de/tech/2024/09/06/vp12-scs-health-monitor-tech-preview/)),
+which exposes information on the performance and error rate of each cloud.
+This provides some transparency on the state of the clouds by constantly running
+scenario tests against them and is tremendously helpful for both the cloud operations
+teams and their customers. Strictly speaking, it is *not* a requirement for the
+SCS-compatible certification, just best practice. It will be part of an
+SCS-sovereign certification though, where transparency on operational aspects
+is included.
+
+## Staying compliant
+
+Once your cloud is listed in the list of certified clouds or in the compliance manager, it
+will enjoy the nightly tests. These might fail for a number of reasons:
+
+* There is a new version of the SCS standards in effect and you need to adjust things.
+* Your cloud was unreachable or otherwise had intermittent issues.
+* You have done changes to your cloud that break SCS-compatible compliance.
+* The test automation engine (github actions / zuul) is in trouble.
+* The tests have a bug.
+
+In either case, this need proper analysis to determine what should be done.
+In the list of certified clouds, the tests are performed by github actions.
+These are executed from the
+[github SCS standards repository](https://github.com/SovereignCloudStack/standards).
+By looking at the logs from the github actions, you can typically see why the failure
+happened. You could of course also do a local test again to see if the issue can
+be reproduced.
+In the compliance manager, we will add links to the log files directly on the table,
+so it will be even easier to find the relevant log.

standards/certification/overview.md

@@ -1,13 +1,5 @@
+# Compliant cloud environments 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_.