Digital Sovereignty considerations

Sovereignty in a general sense

There is no general definition of the term “digital sovereignty”. This makes it difficult for governments and institutions to think about gaining digital sovereignty and to rationally evaluate the available partners and offerings to make a strategically reasonable decision in the end. What should or could be achieved – which advantages and possibilities bring digital sovereignty to governments and nations?

Sovereignty is one of the main preconditions and basis of a nation. It can be condensed to “supreme authority within a territory” (Philpott 2020). But the notion of territory does not need to be restricted to the landmass, but also to resources lying on the territory such as infrastructures, culture, humans, ... food sovereignty, or energy sovereignty (cf. Couture and Toupin 2019).

But what does that mean for national digital space? What exactly does sovereignty in the digital realm refer to? Many attempts have already been made to fundamentally define this term. For instance, the focus group “Digital sovereignty in a networked society” postulated: “Digital sovereignty is an important aspect of general sovereignty, which refers to the ability to use and design digital systems, self-determination over aggregated and stored data, as well as over the related processes” ( German “Digital Gipfel” 2018).

1. Legal dimension

From a legal perspective, digital sovereignty would encompass the ability of a society to define the rules for digital solutions and to also enforce these rules, like national data protection rules and data management norms, for example, the General Data Protection Regulation (GDPR) of the European Union, which aims to govern the collection, processing, and deletion of personally identifiable data to protect the freedom of individuals by giving them some level of transparency and control over their data.

In other parts of the world, the regulations are made on the national level. Every government needs to decide which level of protection should be implemented and how the usage of digital services could compromise this protection level. Which level of security, data protection, and access management is the lowest to achieve? Is this lowest level enough? What needs to be implemented to guarantee the security of national IT and the data of the citizens?

An often-used possible remedy is to create franchise agreements with (local) cloud service providers who operate the software, which does not always fit with the regulations in their respective jurisdictions.3 With this approach neither self-determination nor sovereignty over the means of production are given. Even if local security institutions audit every single modification coming from the outside software provider, these offerings still need a high presumption of trust between software vendors, local franchise partners, and customers.

Questions arise such as:

• Are security updates provided in a timely manner?

• Is operational knowledge around the technology (which may originally not have been designed to be operated by third parties) sufficiently shared and documentation appropriately maintained?

• Isn’t there still a complete dependence on the single proprietary technology provider and operator?

• Are these arrangements compatible with all aims of protection?

These and more questions arise as soon as considering more than just the legal dimension of these offerings. The use of open technologies or solutions developed in the community also has an impact on the binding nature, traceability, and reliability of commitments, as these can be examined at any time. The legal dimension is a base, but creates no digital sovereignty, therefore more dimensions need to be covered which will be discussed in the following sections.

2. Choice

To have real choice, not only must there be several providers, but they must be highly compatible with each other, so choice remains realistic even after having invested in building technology that leverages the services and automation interfaces of one platform. The availability of several highly-compatible options ensures competition and quality. Ideally, the choice also includes a self-hosting option.

3. Technological dimension

Regarding sovereignty over the means of production, it is mandatory to analyze the technological self-determination of digital offerings.

There are first achievements to open source hardware (https://www.opencompute.org/projects), so there is also a possibility to gain more sovereignty and sustainability, but in comparison to open source software, it only starts. Overall hardware is still largely proprietary and can create vendor lock-in. More open-source hardware is needed for true sovereignty.

In the scope of software proprietary licenses and vendor lock-in effects can create dependencies that ultimately contradict a self-determined usage of this technology. The answer is open source. Open source is the key to sovereignty by enabling transparency, peer-reviewed software, flexibility, open source licenses, and avoidance of vendor lock-in:

This is exactly where the importance of open-source software for achieving sovereignty and self-determination becomes evident. Open-source software can be transparently peer-reviewed at any time. Simultaneously, there is no dependency on a single technology provider, and e.g. security updates can be provided by either an established community or a suitable contractor.

Strategically important software should be sustained by an active, open community developing according to open principles like the Four Opens for example.4

The flip side is: that it requires skills and knowledge to be able to practice this self-determination at all. While open source makes skill building possible, the required amount of knowledge can become prohibitive to exercising these possibilities:

4. Dimension of competence

The best software is useless if it cannot be operated confidently. But for this to happen, skills and knowledge must be built up, fostered and retained. In an increasingly competitive market for skilled people and increasingly complex IT systems, this is becoming an ever-greater challenge for governments, institutions, and companies: How can we operate digital offerings in a self-determined, secure and qualitatively excellent manner?

While software as a means of production has been and is being increasingly collectivized thanks to the open source movement, organizations continue to protect operational knowledge like a holy grail. How sovereign can a government and its IT teams act, if precisely this important knowledge only adds to the lottery factor?5

The answer to this must be the collectivization of operational knowledge, just as it is being practised for many years with software code. So, there is an need to build communities who collaborate on exchanging and recording this experience and the tooling built to simplify the automation of operational processes.

For true self-determination in the ever-growing digital realm, there is an urgent need to build skills and share the gained knowledge freely and in unlimited ways also in the realm of operational knowledge. And this is just another urgently needed piece to enhance and grow the overall digital capabilities for achieving sovereignty in the digital realm.

Sources

• Couture, Stephane, and Sophie Toupin. 2019. “What Does the Notion of ‘Sovereignty’ Mean When Referring to the Digital?” New Media & Society 21 (10): 2305–22. https://doi.org/10.1177/1461444819865984.

• Digitale Souveränität und Künstliche Intelligenz – Voraussetzungen, Verantwortlichkeiten und Handlungsempfehlungen des Digital Gipfel 2018

• Philpott, Daniel. 2020. “Sovereignty.” In The Stanford Encyclopedia of Philosophy, edited by Edward N. Zalta, Fall 2020. https://plato.stanford.edu/archives/fall2020/entries/sovereignty/; Metaphysics Research Lab, Stan-ford University.

Example of digital sovereign cloud environment: Sovereign Cloud Stack

The Sovereign Cloud Stack has been granted funding from the German Federal Ministry for Economic Affairs and Climate Action to develop a complete, production-ready, fully open source cloud stack as part of supporting the European Gaia-X initiative. This cloud technology offers scalable cloud infrastructure and container technology with open standards – it can run everywhere (own data centers, hybrid, multi, public, …)! As Germany is a federated state, SCS covers all the demand for centralized and de-centralized cloud usage. The software is provided via GitHub (https://github.com/SovereignCloudStack) – open source, transparent, fully integrated. A significant amount of effort is invested to make SCS fully transparent by creating comprehensive documentation: https://docs.scs.community/docs . SCS provides access management, security, monitoring – to offer a software stack that substantially lowers the bar for providers or IT departments to to build their own cloud environments. It is developed and further improved by a vivid engaged community and a network of partners who ensure a frictionless usage of SCS. It is designed for production-ready enterprise-sized cloud environments and has been adopted by a number of public and private clouds in Europe.

Technical architecture - Basic architecture decisions

• Build complete OSS stack on top of commodity HW

• Put Kubernetes on top of IaaS/Virtualization platform(on top of HW install automation / asset management)

• On-demand k8s cluster lifecylce management and scaling

• Secure isolation by virtualization technology

• Define IaaS and KaaS layers separately – can be used individually (but work well together)

• SW (Reference Implementation) & Standards go hand-in-hand

• Operational tooling part of the solution (covering all layers) : Lifecycle Management, Monitoring, Alerting, Logging, CI

• Identity & Access Management with support for user federation (OIDC and SAML)

• Use existing OSS solutions and standards as much as possible

• Create well-defined platform for well-integrated platform services by 3rd parties(collaborate with EF Xpanse, Glasskube) – option to standardize & implement some later (like building blocks)

Deployment options

Cloud-in-a-box

• Single machine setup for development, testing, demos (~3k€)

• Also starting point for an edge cloud appliance

Virtual deployment: Testbed (4+ nodes/VMs)

• Installing complete SCS on preexisting IaaS (currently only implemented for OpenStack) → testing, CI/CD, learning, development

Blueprints for physical (production-grade) deployments - reworking

• Starting with small hyper-converged setups (half a rack)

• Scalable setups (non-HCI) starting with a rack (~250k€)

• x86-64 commodity server hardware, ARM is WIP, RISC-V planned

Security by design

Using strong isolation for container clusters

• Different tenants receive their own Kubernetes clusters; by default, no cluster sharing happens

• Underlying VMs, network, storage are separated by strong virtualization barriers

Private registry for users

• Make it easy for DevOps teams to enforce their own security vetting processes and control their supply chain

• Vulnerability scanning included in the registry solution

Daily patching supported

• The architecture is built for daily patching (or redeployment) without noticeable customer impact

• This creates a practice of keeping the systems up to date, especially with respect to security patches

Secure Operational practices

• Document updating, patching, security response, … processes to help with secure operations

Air gap mode supported

• Deploying and updating without an internet connection is possible

• Leveraging an internal registry and patch distribution mechanism (includes vulnerability scanning)

Certification

• Budget for security certifications (BSI) with partners – SCS-based PlusCloud Open achieved BSI C5 in Nov 2021

• Pen testing

Standardized (and federative) user & auth management

Supply chain security

• Work with the community on further improving supply chain security (reproducible builds, scanning, …)

Confidential computing

• Work with intel (and AMD) on TDX / SVE enablement for additional protection

IP Management in SCS

Only accept OSI-approved open source licenses in implementation

Open Source health check

• Really Open: Four Opens (Code, Devel, Design, Community)

• Maturity: Quality, Reviews, CI, Maintenance, Standards

• Security: Supply Chain, Sec Response, SecTesting / PenTest

• Activity: Adoption, Community, Ecosystem

• Risk Assessment: Likelihood to fail? Replace? Fork?

• https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/OSS-Health.md

Use OSI licenses (ASL2, MIT, GPL, ...) of upstream projects

• contribute back as much as possible

• prefer copyleft for own independent code (weak copyleft for interface code)

Distributed copyright (like the Linux kernel)

• intentionally prevents dual licensing, license changes

Use Digital Certificate of Origin (DCO, „signed-off-by“)

• documenting willful contributions under accepted license terms

• enforced by pre-merge checks

Resource and cost optimization

• No lock-in => no ability to hold customers hostage, vendors can be changed to suitable to changing requirements (SLAs, support, costs, data center characteristics, ...)

• No expensive cost traps (e.g. outward data traffic)

• Manual scaling or auto-scaling of deployments based on load, response times, time of day and weekday, …

• Power-saving mechanisms active

• Detailed modeling in collaboration with ECO: digit project

Standardization

Preference to leverage/reference/contribute to existing upstream standards

Process: Described in gh:SCS/standards/Standards/SCS-0001-v1

• Lifecycle: Pre-merge Draft → Merged Draft → Stabilized (or Rejection) → Deprecation (all via github PRs)

• Standards are versioned

• Discussed in SCS technical teams, reach out to broader communities when useful, get operator feedback

• Standards should come with compliance check tools

• Providers are more comparable and assessable due to a common technological basis or standardization.

Driven by interoperability needs from users (DevOps teams that operate workloads on SCS infra)

• Internal needs: Container layer creates InterOp requirements to Infra layer, platform services to container layer

Standards are extensible

• Common baseline, growing over time

• Overdelivery allowed

IaaS and KaaS layers currently (both requiring IAM Federation), Platform services in the future

Current focus on SCS-compatible, openness checks (SBOM) and open operations standards in the future

SCS compatible on IaaS layer

• Build on upstream standard: OpenStack powered Compute 2022.11

• Flavor naming and mandatory flavors

• Flavor discoverability

• Image metadata

• IPv4: Private networks, floating IP for public net

• IPv6: Private networks, public provider network

• Entropy sources

• Disk encryption

• Metadata source

• DNS, NTP

• Domain admin role

SCS compatible on KaaS layer

• Build on upstream standard: CNCF certification tests (via sonobuoy)

• CNI with network policies

• Default CSI

• Additional storage classes (WIP)

• K8s version recency and support period

• ClusterClasses (Cluster-API)

• Anti-affinity for nodes

• Optional Ingress (with real client Ips)

• IAM integration

• KubeAPI access controls

• Metrics service

• Optional gitops cluster management

How is SCS developed?

Upstream communities

• OIF: OpenStack, kolla-ansible, kayobe, zuul, …

• CNCF: kubernetes, helm, harbor, openstack-capi-provider

• LF: Linux, KVM, ceph, ...

• OSISM: Integration, Ops tooling (https://github.com/OSISM/)

SCS community

• https://github.com/SovereignCloudStack/Docs https://docs.scs.community/docs

• Contributions from providers, users, volunteers

• IP policy (Various FOSS licenses, Four Opens, DCO, SPDX) – SBOM (ORT)

• Paid development via public tenders (BMWK funded): https://scs.community/Tender/

• Development performed in agile teams coordinated by POs (@OSBA)

• The properties of SCS are not primarily shaped by the business interests of a individual companies and therefore fit more closely to the interests of the user of the plattform

• The best ideas win by community facilitation. New features or improvements can be advanced through community engagement of companies and individuals.

• Align with upstream and contribute back

Open Collaboration Model

• Bi-Weekly sprints: Sprint reviews, backlog refinement, sprint planning via weekly VC (Jitsi)

• Weekly team call (Thu afternoon, SCS Jitsi)

• Taskboard on github, also Reviews, PRs, Issues

• Mailing list, Matrix chat

Open Operations

We build a community of practice

Open Operations builds a community of practice to keep the barrier to entry low and create a thriving environment for comfortable exchange.

We share knowledge

The availability of knowledge and skilled engineers is the limiting factor for many organizations to adopt, leverage, and successfully operate complex technology.

We’re transparent about our incidents

We firmly believe that failures make us experts. The way we handle mistakes is how we become better.

We’re transparent about our operational processes

We share our internal processes for the sake of transparency. We firmly believe that transparency leads to better and more reliable processes.

Links to repros, documentation, information

• All development repositories, everything is openly developed: https://github.com/SovereignCloudStack Published documentation: https://docs.scs.community/docs The information platform for SCS members: https://scs.sovereignit.de/nextcloud/apps/files/?dir=/Sovereign%20Cloud%20Stack&fileid=278 (needs registration) The communication platform: https://app.element.io/#/room/#scs-community:matrix.orgThe project website: https://scs.community Mail: scs@osb