Align Volume (Block Storage) capabilities description between SCS and Gaia-X

[anjastrunk]

There exists a SCS decision record and a standard on volume types and a base class, called Storage Service Offering to describe storage capabilities. Both have to be aligned.

[anjastrunk]

StorageServiceOffering has three different sub-classes:

classDiagram

StorageServiceOffering <|-- FileStorageServiceOffering
StorageServiceOffering <|-- BlockServiceStorageOffering
StorageServiceOffering <|-- ObjectServiceStorageOffering

Loading

As volumes are of type block storage, we have to investigate BlockStorageServiceOffering

[anjastrunk]

The following attributes are mentioned in SCS Volume Type Decision Record:

• encryption: encryption-provider, key size, cipher and control location
• volume type name
• availability zone
• multiattach
• number of replications
• QoS

The following attributes are part of SCS Volume Type Standard:

• encryption
• replication

Gaia-X class BlockStorageServiceOffering offers the following attributes:

• providedBy (mandatory)
• dependsOn
• serviceOfferingTermsAndConditions (mandatory)
• servicePolicy (mandatory)
• dataProtectionRegime
• dataAccountExport (mandatory)
• keyword
• provisionType
• endpoint
• hostedOn
• serviceScope
• legalDocuments
• subContractors
• customerInstructions
• dataPortability
• possiblePersonalDataTransfers
• requiredMeasures
• cryptographicSecurityStandards
• providerContactInformation
• minimumSize
• maximumSize
• storageConfiguration
• lifetimeManagement
• versioning
• storageConsistency
• dataViews
• multipleViews

[anjastrunk]

Taking, what I figured out in my last comments, the following attributes must be generated:

Gaia-X Attribute	OpenStack Attribute
providedBy (mandatory)	Gaia-X expects a link to Gaia-X Credential of CSP as legal person. We already implemented this in PR #55 and can reuse code.
serviceOfferingTermsAndConditions (mandatory)	Resolvable URL to service's terms and conditions. Not discoverable, we use config entry. We already implemented this in PR #55 and can reuse code.
servicePolicy (mandatory)	Not discoverable. We already implemented this in PR #55 and can reuse code.
dataAccountExport (mandatory)	Not discoverable. We already implemented this in PR #55 and can reuse code.
storageConfiguration.storageEncryption	If description contains [scs:encrypted] If description does not contain [scs:encrypted] Problem: class Encryption expects two attributes cipher and keyManagement, which are not discoverable and we have to think about how to set these attributes, manually.
storageConfiguration.redundacyMechanism	Gaia-X Ontology is a bit messed up with respect to block storage offering, which makes it hard to create valid Gaia-X Credentials. I cleaned it up a bit and added missing features. For detail please visit PR#276

[anjastrunk]

Undiscoverability Gaia-X mandatory attributes

Gaia-X models encryption with class Encryption, which has two mandatory attributes, which are not discoverable from cloud. These attributes must be set manually. We have two possibilities to do that:

1. Put undiscoverable attributes in generator's configuration file and write them to Gaia-X Credential of block storage during generation time.
2. Put undiscoverable in separate Gaia-X Credential and them Gaia-X Credential of block storage using linked data principles

Both proposals have different pros and cons. The first proposal is easy to implement, but no scalable as it will blow up configuration file. The second one, requires a more complex implementation, but will be scalable. As we want to support linked data principles, see #73, we decided to go for proposal 2.

[anjastrunk]

Use linked-data principles to add non-discoverable (mandatory) attributes

Linked data offers a possibility spread knowledge about subject in different files. We use this feature to provide non-discoverable (mandatory) attributes. Assume we have an OpenStack volume type, which is encrypted. Encryption itself, can be discovered but not the mandatory attributes cipher and keyManagement. They must be added by CSP manually.

Assuming the example illustrated above, we will have at least two files at the end:

File 1: Output of SCS GX Credential Generator

This file contains all discoverable attributes, such as volume name, but non-discoverable attributes are missing even if they are mandatory.

{
   "@context":{
      "ex":"http://example.com/",
      "gx":"https://w3id.org/gaia-x/development#",
      "qudt":"http://qudt.org/vocab/",
      "qudt-schema":"http://qudt.org/schema/qudt/",
      "xsd":"http://www.w3.org/2001/XMLSchema#"
   },
   "@graph":[
      {
         "@id":"ex:myBlockStorageConfig",
         "@type":"gx:BlockStorageConfiguration",
         "gx:name":"LUKS Encrypted Volume",
         "gx:storageEncryption":{
            "@id":"storageEncryptoin_1"
         }
      }
   ]
}

File 2: Manual written GX Credential

This file contains all non-discoverable attributes of encrypted volume. The glue code between both files is the @id element, which has the same value in both files. I.e. both files containing statements about the same subject, in this case storageEncryptoin_1

{
   "@context":{
      "ex":"http://example.com/",
      "gx":"https://w3id.org/gaia-x/development#",
      "qudt":"http://qudt.org/vocab/",
      "qudt-schema":"http://qudt.org/schema/qudt/",
      "xsd":"http://www.w3.org/2001/XMLSchema#"
   },
   "@graph":[
      {
         "@id":"storageEncryptoin_1",
         "@type":"gx:Encryption",
         "gx:cipher":"RSA",
         "gx:keyManagement":"BYOK"
      }
   ]
}

[anjastrunk]

Support linked data principle comes with one major drawback: We can not generate all Gaia-X Credentials and request for Gaia-X compliance in a glance. Instead, we have to go for a three step process

1. Generator Service Offering Credentials
2. Credentials with manual statements
3. Apply for compliance.

Hence, we have to adapt source code as follows:

• Split generation of CSP and applying for compliance in to separate commands
• Collect all CSP related Gaia-X Credentials to a VP to apply for Gaia-X compliance
• Split generation of Service Offering and applying for compliance in to separate commands
• Collect all Service Offering SP related Gaia-X Credentials to a VP to apply for Gaia-X compliance