Skip to content

Commit 5fd8f08

Browse files
garloffgarloff
committed
Explain SCS DigiSov and Certs. How to get into compliance.
- Explain the motivation for the SCS certification levels rooted in the levels of digital sovereignty. - Give a practical example how to achieve the SCS certification by running the tests. - Hints on how to get listed, why we have the HM there and how to react to failed runs. Editorial note: - This was written up in January 2025 - It was not merged, as the description how to get certified is better done separately, elsewhere - Resurrect it, as the explanation of digital sovereigtny relative to SCS certification is useful - ToDo: Drop the duplicate pieces on testing and certification process Signed-off-by: Kurt Garloff <kurt@garloff.de>
1 parent 32a9cd6 commit 5fd8f08

5 files changed

Lines changed: 404 additions & 2 deletions

File tree

‎.lintstagedrc.json‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
{
22
"*": "prettier --ignore-unknown --write",
3-
"*.md": "markdownlint-cli2-fix"
3+
"*.md": "markdownlint-cli2"
44
}

‎sidebarsStandards.js‎

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ const sidebars = {
77
label: 'Certification',
88
link: {
99
type: 'doc',
10-
id: 'certification/overview'
10+
id: 'certification/digisov-and-cert'
1111
},
1212
items: [
1313
{
@@ -24,6 +24,9 @@ const sidebars = {
2424
label: 'Compliance Check Pipeline',
2525
id: 'certification/pipeline'
2626
}
27+
'certification/getting-scs-compatible-certified',
28+
'certification/test-and-adapt-example',
29+
'certification/overview'
2730
]
2831
},
2932
{

‎standards/certification/digisov-and-cert.md‎

Lines changed: 121 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,121 @@
1+
# Digital Sovereignty and SCS certification
2+
3+
## The taxonomy of digital sovereignty
4+
5+
As published in [DuD](https://rdcu.be/cWdBJ) (German, English version in
6+
[the cloud report](https://the-report.cloud/why-digital-sovereignty-is-more-than-mere-legal-compliance/))
7+
and being summarized nicely in a [cloudahead article](https://www.cloudahead.de/der-freiheitskampf-des-sovereign-cloud-stacks),
8+
we differentiate between several levels of digital sovereignty.
9+
We'll skip stage 0, introduced by Gregor Schuhmacher in his description, which
10+
specifies using a cloud at all as the pre-step to be taken. This has relevance,
11+
as some companies continue to call solutions that are not on-demand, not
12+
self-service API driven, not metered
13+
(see [NIST definition of cloud](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf))
14+
to be (private) clouds. We talk about real clouds, where deployment of infrastructure
15+
is API-driven, unlocking DevOps teams productivity.
16+
17+
The levels as seen by the SCS movement are:
18+
19+
1. Control over data and data sharing and ability to fulfill regulatory requirements (GDPR)
20+
2. Capability to chose between *highly compatible* operators, this way enabling a provider
21+
switch or using several providers in a federated fashion. This also includes the
22+
possibility to run your infrastructure in a *highly compatible* manner.
23+
3. Capability to influence and shape the infrastructure, enabling innovation at the
24+
infrastructure layer.
25+
4. Transparency over operational aspects of running infrastructure, this way supporting
26+
to overcome a skill gap to being able to operate infrastructure in a highly reliable
27+
manner.
28+
29+
These aspects of sovereignty drive the work from the SCS team.
30+
31+
Level number 1 is sometimes referred to as "data sovereignty". Achieving it does require
32+
cloud infrastructure and cloud operations that can not be interfered with by actors that
33+
are outside of the respective jurisdiction. For Europeans that need to observe GDPR, this
34+
excludes using US clouds for personally identifiable information, expecting that the
35+
adequacy decisions for the US do not fully address the risks. The SCS project does not
36+
have deep legal expertise and refers to the work from [noyb](https://noyb.eu/)
37+
and [ENISA](https://www.enisa.europa.eu/) here.
38+
39+
In order to achieve level 2,
40+
the SCS community has worked on standards that define the APIs and the infrastructure
41+
behavior, so application developers and application operators can deploy the same application
42+
using the same automation and rely on the same infrastructure behavior to operate the
43+
application in a resilient way. The standards allow for switching providers or to use
44+
several providers in a federated way. Operating own infrastructure according to the same
45+
standards is also possible, allowing for hybrid cloud setups without technical barriers.
46+
47+
Level 3 drives the work on a comprehensive openly developed open source software stack,
48+
allowing operators to use, study, change and redistribute the software according to the
49+
[Four Freedoms](https://en.wikipedia.org/wiki/The_Free_Software_Definition) of free software. We are requiring
50+
a complete stack that uses real open source licenses (as defined by [OSI](https://opensource.org/))
51+
as to ensure that users have the four freedoms, the right to use, study, modify, (re)distribute
52+
the software that drives the cloud stack. To ensure that this does not require extensive
53+
and expensive forking, we further require the [Four Opens](https://openinfra.dev/four-opens/)
54+
of the Open Infra Foundation here. The software can be used to provide cloud services
55+
for others (public cloud) or just for your own community (community cloud) or
56+
internal (private cloud) needs.
57+
58+
Level 4 addresses the skills and transparency aspects. Operating highly dynamic distributed
59+
systems in a reliable manner requires knowledge and experience - engineers with these skills
60+
are scarce. To address this, the SCS team networks operations staff from providers and helps
61+
to share and distill common knowledge that help everyone to be more successful. SCS has
62+
thus been driving the [Open Operations](https://openoperations.org) initiative.
63+
64+
Levels 2 and 3 are sometimes related to the term "technological sovereignty", indicating
65+
that the ability to control and shape the technology.
66+
67+
## The SCS certification levels
68+
69+
Corresponding to the levels of digital sovereignty in the SCS taxonomy, SCS defines
70+
SCS certification levels
71+
72+
1. (Defined outside of the SCS scope)
73+
2. SCS-compatible
74+
3. SCS-open
75+
4. SCS-sovereign
76+
77+
### Why no SCS certification for GDPR?
78+
79+
SCS significantly lowers the bar to offer real cloud services. These can be used internally
80+
(private cloud) or to offer services for your community, your region or country. The vision
81+
is to have a network of providers. We expect most if not all of them to be operated in ways
82+
that fulfill the European GDPR regulation; it is also possible to operate clouds that fulfill
83+
special regulation, e.g. in the banking or insurance sector.
84+
85+
SCS is not in a position to judge this and thus defines no own label / certificate to
86+
vouch for regulatory compliance. We typically refer to the ENISA for GDPR considerations
87+
and also recommend to take the Gaia-X labels into account here.
88+
89+
## Status of SCS certification for cloud operators
90+
91+
As of September 2024, we have not yet formalized the requirements for SCS-open and SCS-sovereign
92+
certification.
93+
94+
The technical compatibility validation corresponding to the SCS-compatible certification does
95+
exist since more than a year. There are certificates for two layers of the SCS architecture
96+
stack:
97+
98+
* The virtualization layer: SCS-compatible IaaS
99+
* The container layer: SCS-compatible KaaS
100+
101+
For each of these, technical tests are being run to test service offerings for compliance.
102+
The standards and the corresponding tests are versioned. The SCS-compatible certification
103+
for a specific layer (currently IaaS or KaaS) and version is called a *certification scope*.
104+
Please see [Scopes and Versions](scopes-versions.md) for detailed definitions.
105+
106+
As of September 2024, the latest SCS-compatible certification scope on the IaaS layer is
107+
SCS-compatible IaaS v4. For November 2024, SCS-compatible IaaS v5 and the first Kaas
108+
scope SCS-compatible KaaS v1 are planned.
109+
110+
## Certification for non-operators
111+
112+
Software can deliver infrastructure components for operators to provide SCS-compatible
113+
IaaS or KaaS; it is planned that infrastructure software can also receive SCS certification.
114+
115+
Likewise, applications can be developed in a way that they will work without any changes on
116+
all SCS-compatible IaaS or on all SCS-compatible KaaS (or may require both). It is planned
117+
that such software can also be certified.
118+
119+
Implementation partners from the SCS ecosystem may support operators (CSPs) to build
120+
and operate SCS-compatible infrastructure. A certification program that certifies the
121+
skills and experience of such partners is planned as well.

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

Lines changed: 113 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,113 @@
1+
# Getting SCS-compatible certification (for operators)
2+
3+
## Process overview
4+
5+
The SCS Certification is a technical certification:
6+
The Operator needs to fulfill technical requirements, such as providing certain
7+
APIs and guaranteeing certain platform behavior in order to be certifiable.
8+
9+
These requirements are meant to provide guarantees to their customers, allowing
10+
them to rely on certain features to be available and on certain system behavior
11+
that lets their applications run in a reliable way.
12+
13+
The SCS certification process typically consists of a few simple steps:
14+
15+
1. Running the SCS compliance test suite and adjusting the infrastructure until it passes.
16+
2. Any additional declarations (for non-testable aspects) are written and passed to the SCS Forum.
17+
3. The operator must be a member ("shaper" or "advisor" level) of the Forum SCS-Standards in the
18+
OSB Alliance (a non-profit) and pay the respective membership fees. Alternatively fees can
19+
be paid without becoming a member.
20+
4. The cloud can be listed on the SCS pages as SCS-compatible with a compatibility status that is
21+
updated on a daily basis. SCS then tests the infrastructure on a daily basis.
22+
23+
## Self-testing and technical adjustments
24+
25+
In order for a cloud service offering to obtain a certificate, it has to
26+
conform to all standards of the respective scope, which will be tested at
27+
regular intervals, and the results of these tests will be made available
28+
publicly. For more details on how to become certified, please consult the
29+
corresponding [document](/standards/scs-0004-v1-achieving-certification).
30+
31+
The best approach to get your cloud into compliance is by installing the
32+
test suite locally. Have a look at the [example](/standards/test-and-adapt-example).
33+
34+
A description how SCS-compatible IaaS compliance can be achieved on environments that use different
35+
OpenStack implementations is written up in a blog article
36+
[Cost of making an OpenStack Cluster SCS compliant](https://scs.community/de/2024/05/13/cost-of-making-an-openstack-cluster-scs-compliant/).
37+
38+
## Declarations
39+
40+
For the SCS-compatible IaaS v5 standard, the providers must - if they implement availability zones
41+
at all (which is optional) - guarantee certain levels of independence for these. This can not
42+
be fully tested by an automated test. The process thus envisions that providers must create some
43+
documentation on the physical infrastructure and how it maps to availability zones and declare that
44+
this documentation reflects the truth. SCS will review the docs and judge whether they meet the
45+
criteria. In case of doubt, audits can be performed.
46+
47+
## Forum SCS-Standards @ OSBA
48+
49+
The SCS brand belongs to the Open Source Business Alliance e.V. (OSBA), an non-profit organization and
50+
association for the Open Source Industry in Germany. The OSBA creates the Forum SCS-Standards
51+
which performs the work to evolve the SCS standards, develops the tests and perform the certification
52+
process.
53+
54+
Members of the OSBA can become also member of the Forum SCS-Standards for an additional membership
55+
fee, providing the financial resources for the Forum to do its work. Membership in the OSBA is
56+
open to any organization that supports the goals of the OSBA.
57+
Alternatively, a certification fee can be paid without any membership; the fee corresponds to the
58+
lower tier membership fee.
59+
60+
## Getting listed and tested
61+
62+
When all tests are passing, all needed declarations are done, fees for the certification or the
63+
membership in the Forum SCS-Standards at the OSBA have been paid, the infrastructure service
64+
can become officially certified.
65+
66+
The SCS team will add the cloud to the [list of certified clouds](https://docs.scs.community/standards/certification/overview)
67+
on the SCS docs page. This can be used to prove to customers that the cloud is SCS compliant.
68+
Note that there will be a nightly job that tests the cloud for compliance, which will be
69+
triggered by SCS infrastructure (zuul). For this, access to a tenant on the cloud needs
70+
to be provided free of charge. (This only requires very low quota, one VM is created for a minute
71+
in one of the tests.)
72+
The list of certified clouds will be replaced by the
73+
[compliance monitor](https://compliance.sovereignit.cloud/page/table) soon.
74+
75+
For clouds not being accessible from the outside, a VPN tunnel or a local monitoring
76+
job (with result upload) can be used.
77+
78+
Next to the addition into the list, we also plan to create an SCS-certified badge that
79+
operators will be allowed to use in their marketing material as long as they fulfill the
80+
certification conditions.
81+
82+
Note that for almost all certified clouds in the list of certified clouds, we also
83+
have a health monitor running (currently still
84+
[openstack-health-monitor](https://github.com/SovereignCloudStack/openstack-health-monitor/),
85+
but soon the new [health-monitor](https://scs.community/de/tech/2024/09/06/vp12-scs-health-monitor-tech-preview/)),
86+
which exposes information on the performance and error rate of each cloud.
87+
This provides some transparency on the state of the clouds by constantly running
88+
scenario tests against them and is tremendously helpful for both the cloud operations
89+
teams and their customers. Strictly speaking, it is *not* a requirement for the
90+
SCS-compatible certification, just best practice. It will be part of an
91+
SCS-sovereign certification though, where transparency on operational aspects
92+
is included.
93+
94+
## Staying compliant
95+
96+
Once your cloud is listed in the list of certified clouds or in the compliance manager, it
97+
will enjoy the nightly tests. These might fail for a number of reasons:
98+
99+
* There is a new version of the SCS standards in effect and you need to adjust things.
100+
* Your cloud was unreachable or otherwise had intermittent issues.
101+
* You have done changes to your cloud that break SCS-compatible compliance.
102+
* The test automation engine (github actions / zuul) is in trouble.
103+
* The tests have a bug.
104+
105+
In either case, this need proper analysis to determine what should be done.
106+
In the list of certified clouds, the tests are performed by github actions.
107+
These are executed from the
108+
[github SCS standards repository](https://github.com/SovereignCloudStack/standards).
109+
By looking at the logs from the github actions, you can typically see why the failure
110+
happened. You could of course also do a local test again to see if the issue can
111+
be reproduced.
112+
In the compliance manager, we will add links to the log files directly on the table,
113+
so it will be even easier to find the relevant log.

0 commit comments

Comments
 (0)