SCONE Session Language (v0.2)

The SCONE session language is used to create session descriptions that entail all security-relevant details of a SCONE application.

A SCONE application can consist of one or more session descriptions. Each session description defines a set of

• services that are part of the application,
• secrets that are securely stored and passed to the services,
• images that define which regions of a container (image) are encrypted or authenticated,
• volumes which are like docker volumes but encrypted, and
• access policy that defines who can read or modify the session description.

The session language is a subset of YAML, i.e., a session description is valid YAML. It is similar to and takes its bearing from docker-compose files. As a session description is typically stored in a file, we use session file as a somewhat interchangeable synonym for session description. We use the terms session description and session policy (or just policy) interchangeably.

Session Description Hash

Each session description has a unique hash value, in short just session hash. This value is used to reference the session in multiple situations. For example, when a session shall be updated the hash of the predecessor session has to be provided to ensure continuity, i.e., no lost-updates.

The session hash is deterministically calculated from the session description, such that any modification to the description would yield a different hash. Moreover, the calculation is cryptographically sound in the sense that a malicious operator can not come up with a modified session description that has the same session hash, i.e., it is Preimage-Attack resistant.

The exact procedure of how the session hash is obtained is an implementation detail.

Session Description Structure

There are a number of top-level keys in a session file.

Version

This document describes version 0.2.

version: "0.2"

Note

Without a version field, version 0.1 is assumed, make sure to include the field in all session descriptions in order to use version 0.2.

Session Name

Every session description has to provide a session name, or short just name. The session name is used to reference a session over the course of its lifetime: while a session hash identifies a unique, not mutable description of a session, the session description references by a session name can be changed by the session's owner. Thus, the session name is the primary property with which a session is referenced outside of session management.

As sessions will be routeable in a future version of CAS and session names are the primary way of referencing a session, they have to obey certain restrictions regarding the allowed character set. To prevent issues with future use of session names within URIs their characters have to be drawn from the "Unreserved Characters" in URIs as defined by RFC3986. Further, we set a somewhat arbitrary restriction of a maximal length of 128 characters. In PCRE the match clause matching valid session names would be [A-Za-z0-9_\-.~]{1,128}.

name: my-testing-session

Providing a session name is mandatory.

Predecessor Session

If a session description is an update for a previously existing session, i.e. the session's name is already in use, it has to include the previous session's hash to detect and prevent lost updates.

predecessor: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Note

The value has to be 32 hex encoded bytes.

When creating a session, no predecessor session exists and hence no predecessor key is permitted.

Service Description

Services of a SCONE application are described below the services top-level key. A service in a SCONE session is a SCONE program with a specific software state and configuration. For now, there can be an unlimited number of instances of a service.

In the current version, the service description specifies the service configuration and which software (code) is allowed to access it. A service configuration consists of the command to be executed, any environment variables and the process working directory from which path resolution of relative paths starts. These properties may contain secrets and would be prone to inspection and manipulation by adversaries.

services:
  - name: my-test-service
    command: test --arg=value
    environment:
        VAR_1: value
    pwd: /

name

To be able to identify a service, every service has to have a name key. As the name will be part of the routeable session identification in the future, its character set and length is restricted in the same way as the session name is.

    name: my-test-service

Providing a service name is mandatory.

command

The command of a service is a sequence of the program's name plus any command-line arguments that have to be provided for it to deliver the expected service.

Note

The first element of the command, the program name, should match the actual program's file name. Although not enforced, in the future automatic scheduling will not function properly if the provided program name does not match.

    command: test --arg=value

The command can be specified as a list, as well. This is helpful in situations where the automatic whitespace splitting would rip arguments apart.

    command: ["test", "--my_name", "Franz Gregor"]

Note

Command arguments have to be C-String compatible, i.e., they are not allowed to contain a NULL byte.

environment

The environment variables provide a process with values that are needed to provide the expected service. As we cannot trust pre-existing environment variables, only the environment specified in the session policy will be available to the SCONE program.

    environment:
        VAR_1: value

Note

• Variable names and values have to be C-String compatible, i.e. they are not allowed to contain the NULL byte. Moreover, variable names are not allowed to contain the equal (=) sign.
• Environment variables that are consumed during enclave creation (e.g., SCONE_HEAP), or used by the SCONE runtime (e.g., SCONE_CAS_ADDR) should not be included in the list of environment variables for the service as they will have no effect. Instead, they should be provided directly during program invocation. Note that the value of SCONE_HEAP affects mrenclave and via mrenclave, a session description can also limit the set of permitted SCONE_HEAP values.

pwd

The process working directory (pwd), or current working directory (cwd), is the directory from which relative paths are resolved. For example, a program writing a private key to private.key with pwd of /encrypted/ would resolve actually write to /encrypted/private.key. Changing the pwd to /plaintext/ before the writing would lead it to write the private key to /plaintext/private.key instead. To prevent this kind of manipulation the pwd of a SCONE service has to be specified explicitly in the session description.

    pwd: /home/user/scone/encrypted

Note

Please note that: - The specified directory has to exist in the environment the SCONE program will be executed in. If it is not found, the program cannot start. - The provided value has to be C-String compatible, i.e. it is not allowed to contain the NULL byte. - The allowed character may be further restricted by the used file system.

Image

A service can optionally use an image, which has to be specified as part of the session (see Section Images).

services:
  - name: my_service
    image_name: my_image

Images must be specified if their volumes or secret injection files should be used by a service.

Attestation

Attestation is the process of verifying a remote SCONE program's integrity ensuring it has not been (maliciously) manipulated. SCONE programs have to engage into attestation with CAS to be allowed to access their service's configuration and secrets. That is, only SCONE programs that can show (using attestation) that they satisfy a certain attestation policy are provided with arguments, environment variables, and secrets.

Measurement based Attestation

Measurement-based attestation gives access to service secrets based on the enclave measurement value, abbreviated as mrenclave. An enclave measurement value uniquely identifies its initial state. The measurement value of a SCONE program can be determined by running it either with SCONE_VERSION or SCONE_HASH environment variables set.

For example, if you have an executable go-webserver you can determine its measurement value by executing:

$ SCONE_HASH=1 ./go-webserver
d08b7351eeb8d5c0653d32794218f183ac9c6fa3923b67052752f78a3559de61

Any modifications to the executable, malicious or not, will void access capabilities.

A service can define a list of mrenclaves that are allowed to get access to the configuration as follows:

    mrenclaves: [d08b7351eeb8d5c0653d32794218f183ac9c6fa3923b67052752f78a3559de61]

For example, you can define mrenclaves for different permitted HEAP_SIZEs. Also, to permit a smooth transition to new service versions, you can first add the mrenclaves of the new version, upgrade the services, and then remove the mrenclaves of the old service version.

Note

• The enclave measurement value (mrenclave) has to be a sequence of 32 hex encoded bytes.
• mrenclave is mandatory.

Secrets

Secrets are defined in the secrets section of the session. Each secret is uniquely identified with a name. The values of secrets are either generated by CAS or are explicitly given in the session. The former has the advantage that the secret value can be ensured to be never known by any human.

Secret Kinds

In most cases, the kind of a secret has to be specified as well. This is necessary for CAS to know how to generate its value or how to interpret the value provided in the session, in the case of explicit secrets.

We support these four kinds of secrets: ascii, binary, service leaf and intermediate certificates.

ASCII Secrets

An ASCII secret is a string compromised of ASCII characters guaranteed not to contain NULL bytes.

Explicit Secret Values

In case of an explicit secret, the value can contain all characters that can be put into a string in YAML, for example:

secrets:
    - name: my_explicit_ascii_secret
      kind: ascii
      value: "secret-value"

Note that explicit secret values can contain any character that can be represented in YAML. In particular, newline and escape sequences can be put into such a secret. The only exception to this rule is the NULL byte that can not be part of an ascii secret. Be sure that your application can handle these edge-cases.

Generated Secret Values

If no value field is specified, CAS will generate a secret value on-demand. The generated string will only contain printable ascii characters. In this case, you may specify the length of the string to generate with the size field. If no size is given, a default length of 20 will be used.

secrets:
    - name: my_generate_ascii_secret
      kind: ascii
      size: 12

Binary Secrets

binary secrets behave similar to ascii secrets except

• they can contain NULL bytes,
• generated values are not restricted to printable ascii characters, and
• explicit secret values have to be specified encoded in hex.

secrets:
    - name: my_explicit_binary_secret
      kind: binary
      value: DEADBEEF

Certificates

CAS can generate X509v3 certificates as well. In fact, CAS provides a whole certificate PKI.

There are two kinds of X509 certificates that can be generated: leaf and intermediate certificates. Their main difference is in their capability to sign other certificates. Leaf certificates are indicated with x509 and intermediate certificates with x509-ca.

secrets:
  - name: my_leaf_certificate
    kind: x509
  - name: my_intermediate_certificate
    kind: x509-ca

Note that certificates have to be generated by CAS - they cannot be specified by the user.

Certificates differ from other secrets in terms of access. Please see the Secret Access chapter for the details.

Session Certificate

Each certificate generated in a session is signed by the session certificate. The session certificate can be made explicitly available with the session-ca secret kind. This, in particular, allows exporting the session CA certificate to other sessions that can then be used to verify that incoming TLS connection are under the control of the session.

secrets:
  - name: exporting-session-ca-cert
    kind: session-ca
    export:
      - another-session

Note that, while normal certificates (x509, or x509-ca) expose also their key, session certificates do only expose their certificate.

Certificates differ from other secrets in terms of access. Please see the Secret Access chapter for the details.

Secret Access

Secrets are injected via standard means (program arguments, environment, and configuration files) into a service. Secret values are not directly included in a service's configuration as this would bound the service to specific secrets. Instead placeholder variables are put that are replaced during runtime in the service. These placeholders are of the form $$SCONE::secret_name$$.

For example, to inject a secret into a service's program arguments its command field in the session description could look like this:

    [...]
    command: service_name --private-key $$SCONE::service_private_key$$ --non-confidential-argument 1234 --non-confidential-flag
    [...]

In the above example, the command's program arguments will be presented to the service with $$SCONE::service_private_key$$ replaced by the actual value of service_private_key.

To inject secrets into a service's environment the session description could contain this:

    [...]
    environment:
      FILE_ENCRYPTION_KEY: "$$SCONE::MY_SERVICES_ENCRYPTION_SECRET$$"
    [...]

Note

Secrets referred to (service_private_key and MY_SERVICES_ENCRYPTION_SECRET in the above example) have to be either defined in the secrests section of the session description or imported from another session.

Certificate Values

Certificate secrets may be composed of multiple values. For once, there is obviously the certificate itself, then their is the private key, and lastly, they might have their certificate chain attached.

These values are available with suffixes to the secret name in the placeholder. Consider a certificate with name my_cert, the following placeholders are available for secret consumption: * $$SCONE::my_cert.crt$$ delivers the certificate in PEM-encoding, * $$SCONE::my_cert.key$$ delivers the certificate's private key in PEM-encoding, and * $$SCONE::my_cert.chain$$ delivers the certificate's chain in PEM-encoding.

Note that only the .crt suffix - i.e., the certificate in PEM-encoding - is guaranteed to exist. The key, for example, is not available for session ca certificates. And the chain is not present on imported certificates.

Secret Injection Files

A secret injection file is a file in the file system that will be updated with secrets received by the runtime from CAS. They use the same secret placeholders that can also be used in program arguments and environment variables.

For example, imagine a service configuration file containing a password. Simply writing the password into the file in cleartext would leak it - that is not an option. Using SCONE's filesystem shield to encrypt the file complicates the setup, and - if distributed as part of an image - would require users to change the encryption keys in order to protect their individual passwords. Instead, a secret injection file allows to specify a placeholder for the password, which will be dynamically replaced at runtime through the means of secret injection:

/etc/mysql/my.cnf:

[client]
user=mysqluser
password=$$SCONE::mysqlpass$$

The path to this configuration file must be specified as part of an image (see Images). The corresponding session would look like this:

services:
  - name: my_database_client
    image_name: my_db_client_image

images:
  - name: my_db_client_image
    injection_files:
      - /etc/mysql/my.cnf

Alternatively, the file's content may be specified within the session:

services:
  - name: my_database_client
    image_name: my_db_client_image

images:
  - name: my_db_client_image
    injection_files:
      - path: /etc/mysql/my.cnf
        content: |
          [client]
          user=mysqluser
          password=$$SCONE::mysqlpass$$

The content specified in the session file can contain multiline strings. This way, entire configuration files can be embedded in the session description, even if no secret injection is required. Producing valid multiline strings in YAML can be challenging - https://yaml-multiline.info/ can be of great help to find the desired syntax.

Secret injection files are prepared during SCONE runtime initialization. If the file content is not provided in the session, the file at the specified path is opened, potentially through SCONE's filesystem shield, and read into memory. The secret injection is applied and the resulting file is put into SCONE's in-memory file system at the specified path. Any application requests regarding this file are served from this in-memory file system. Thus, modifications to secret injection files are not propagated into the file system and are not persistent across program invocations.

Secret Sharing

Session owners can decide to share their secrets with other parties to enable collaboration. For example, database operators could use TLS to implement access control to databases. They would define an access certificate, configure the database to only allow connections from said certificate and export it to the database client:

name: database_operator

secrets:
  - name: database_access_certificate
    kind: x509
    export: database_client

The secret owner might also specify multiple receiving sessions at once:

name: database_operator

secrets:
  - name: database_access_certificate
    kind: x509
    export:
      - database_client
      - another_client

Furthermore, the export might be restricted to certain instances of the importing session. For more details, see the concrete format by which other sessions can be referenced in Referencing Other Sessions.

The database client, on the other hand, would import it and could use it in their session as if it was their own certificate:

name: database_client

secrets:
  - name: database_access_certificate
    kind: x509 # optional
    import: database_operator

On the importing side, the kind of a secret can be optionally defined to ensure imported secrets match a specific form, but this is not strictly necessary.

In very specific cases, secrets may also be made public (exported to any session without authentication) - this may be useful when, for example, defining certificate hashes:

name: policy_checker

secrets:
  - name: policy_checker_certificate_hash
    kind: ascii
    value: "ce29906ee68a580410f0d41c67984ff7b384310e84dadf2b07c21252aa01fe1f"
    export_public: true

This hash can be used in another session's access control policy through secret substitution (see Access Control):

name: checked_session

secrets:
  - name: policy_checker_certificate_hash
    import: policy_checker

access_policy:
  read:
    - "$$SCONE::policy_checker_certificate_hash"

Warning

By using export_public: true, the whole world will be able to see the secret value. Make sure this is your intention.

Secret Migration

When uploading a new session which has a predecessor session, secret migration takes place. In short: secret values which were generated as part of the old session will be kept when the new session defines a secret with the same name and compatible kind.

Example old session:

secrets:
    - name: my_generated_ascii_secret
      kind: ascii
      size: 12
    - name: foobar
      kind: binary
      value: DEADBEEF

Example new session:

secrets:
    - name: my_generated_ascii_secret
      kind: ascii
      size: 12
    - name: foobar
      kind: x509

In the given example, the value of my_generated_ascii_secret will be kept, as it stays an ASCII secret of the same size, whereas foobar will be freshly generated, since its kind changed.

Secret migration also takes place when using a different session description language version (e.g. 0.1 -> 0.2)! For details, see the session secrets migration documentation.

Volumes

Similar to Docker, the volumes keyword allows to specify file system regions that can be mounted into the file system in addition to the regions specified by the main file system protection file of a service. Each volume has an arbitrary but unique name. In order to grant services access to a volume, it first has to be included in an image (see section Images). Subsequently, the image can be specified for a service (see section Service Description), and all image-defined volumes will be mounted automatically.

Note

The volume name is not the volume's mount point. The latter is defined as part of an image.

Each volume can have a file system protection file key (fspf_key) and file system protection file tag (fspf_tag):

volumes:
  - name: my_database
    fspf_key: f843051d21afa9e52a5b54a708a8032bc49581e982696a81393b8da4a32d00b8
    fspf_tag: 8d8fbe332fb9c893020be791ccd3e8a8

fspf_key is the key used to encrypt volume.fspf (file system protection file for the volume) and fspf_tag describes the initial state of the volume. On each volume update (e.g., creation of a file in the region or update of an existing file), the SCONE runtime will send a new fspf_tag to CAS to ensure integrity and freshness of the volume state.

If neither fspf_key nor fspf_tag are specified, a volume will be automatically initialized during the first use:

volumes:
  - name: my_database

The volume will contain a single encrypted region, and a new key will be generated by CAS to encrypt volume.fspf. Once initialized, CAS and the runtime will work together to track the updates of the volume, similar to a regular volume. This ensures that a volume can be initialized only once. Use of automatically initialized volumes ensures that the key for the file system is only visible inside of CAS and the application(s) that get access to this volume, i.e., no system administrator will ever see the volume key.

Volumes may be exported to other sessions, which implies authorizing the other sessions to decrypt and read existing files or encrypt and store new files:

volumes:
  - name: my_database
    export: another-session

or

volumes:
  - name: my_database
    export:
      - another-session
      - foobar:668e9aaba22c7631bbcc89b627d77e53539bcaade9e7c2c08242f56aab272088

The concrete format by which other sessions can be referenced is described in section Referencing Other Sessions.

Similarly, volumes may be imported from another session (in which case fspf key/tag and export list must be omitted):

volumes:
  - name: my_database
    import: the_exporting_session

Images

The images keyword allows specifying images usable by services (see section Service Description). Each image has an arbitrary but unique name:

images:
  - name: my_image

Images may define access to volumes, by referencing a previously declared volume's name and giving it a mount point (path):

volumes:
  - name: my_database

images:
  - name: my_image
    volumes:
      - name: my_database
        path: /media/database

Note

The given path must already exist in the filesystem, e.g., through a mounted docker volume. The information provided as part of the session description are only used to encrypt and authenticate all of the volume's files. The CAS does not actually store the encrypted files.

Images may also contain secret injection files, a way to inject secrets into configuration files:

images:
  - name: proxy_image
    injection_files:
      - /etc/nginx/nginx.conf
      - path: /etc/mysql/my.cnf
        content: |
          [client]
          user=mysqluser
          password=$$SCONE::mysqlpass$$

For details, refer to section Secret Injection Files.

Access Control

Any operation on a session description requires permission. If the entity requesting a certain operation is not explicitly permitted to perform said operation, the request will fail. access_policy keyword allows to specify lists of entities that are allowed to perform the following operations:

• read: permit to read the policy - without the secrets
• update: permit to update the policy. Note that entities listed here must also be present under read.

Granting permission to a certain entity to perform one of these operation involves adding their public certificate to the list of authorized entities. This certificate shall be used when establishing connection to CAS (see API Documentation, Authentication section). TLS ensures that the client is in possession of the corresponding private key. When using the scone CLI, the user certificate can be shown by running scone self show.

Besides public certificates, the following values can be used:

• SHA256 hash of a public certificate in PEM format. Note that CAS supports only LF (\n) line endings. Please make sure your certificate file adheres to this requirement. Otherwise, you will not be able to perform the operation. When using the scone CLI, the hash can be shown by running scone self show. The hash can also be calculated by the sha256sum tool:

$ sha256sum cert.pem
1809fafa119b97db77a43562c5241b3db33d21a85516e35ebe0a19bf0e3d29ee  cert.pem

• CREATOR keyword: permit access to the creator of the policy: this is the public key of the TLS client certificate used when creating this session
• ANY keyword: permit access to any entity. If ANY is specified, there must be no other entries in the list for this operation
• NONE keyword: deny all requests for a particular operation. If NONE is specified, there must be no other entries in the list for this operation
• $$SCONE::secret-name$$ will dynamically use the value of a secret with the given name (secret-name) at permission evaluation time. The replaced value must be either CREATOR (ascii), a SHA256 hash (ascii) or certificate as defined above. It is possible to use explicit secrets, generated secrets, and imported secrets. When referencing X.509 certificates, the trailing .crt after the secret name can be specified, but may also be omitted. If the mentioned secret does not exist, cannot be read, or has an incompatible value, it will be ignored.

By default, the access policy is defined as follows:

access_policy:
  read:
   - CREATOR
  update:
   - CREATOR

If the session description does not overwrite some of the operations, default values are used.

Example policy:

access_policy:
  read:
    - CREATOR
    - 1809fafa119b97db77a43562c5241b3db33d21a85516e35ebe0a19bf0e3d29ee
    - |
      -----BEGIN CERTIFICATE-----
      MIIFwTCCA6mgAwIBAgIUCF1MVJJ78BIf4WmTE24aAX7NlHowDQYJKoZIhvcNAQEL
      BQAwcDELMAkGA1UEBhMCVVMxDzANBgNVBAgMBk9yZWdvbjERMA8GA1UEBwwIUG9y
      dGxhbmQxFTATBgNVBAoMDENvbXBhbnkgTmFtZTEMMAoGA1UECwwDT3JnMRgwFgYD
      VQQDDA93d3cuZXhhbXBsZS5jb20wHhcNMTkwNzIyMTU1NTExWhcNMTkwODIyMTU1
      NTExWjBwMQswCQYDVQQGEwJVUzEPMA0GA1UECAwGT3JlZ29uMREwDwYDVQQHDAhQ
      b3J0bGFuZDEVMBMGA1UECgwMQ29tcGFueSBOYW1lMQwwCgYDVQQLDANPcmcxGDAW
      BgNVBAMMD3d3dy5leGFtcGxlLmNvbTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
      AgoCggIBALVbVIrBAlzDOztWs9hZr5kvYoUwq/hL7zaMrYKBLQJZFNbhmMaUsW7A
      Fzj87dzP3xIf4c2r3IGJSukv7hJpaJ2Ykv80i3C7EiFgaDV/+JP9d/GjsvcW20zH
      mtJcBIkdkqPt1epOtxsMyJGZL+34DoWOqgY7up6nCirr+MeUxYJ/dWBFD1j0iuHl
      Y+rEMsv4xFBndgLmMQNlcMyXtBgPls4EgnDfnjICqIYMHt6PG+kwoR4tbs+v2Gsl
      vqldxI7efErZh+kKtjtFxt6qzrypUs9bYgH3tsaUE0xYeK/A2llylJzPOv6vkCqg
      vPOJETcZyoeH46niITdPssYr4yPQOxn/a7WS+7Mn2y6o5z4Q+DkB96lzUyvVJnwO
      aorzec0PaB/qqYrHqVfftMu4thMwHGB8CrGUiq/ImHPWkfobyVcMYJ0/LaLSDHFj
      1hN36VkzWqQcCM6ymhjx9Lpfzzxna5910jE86zb1cMnD/eAAd90jpJvGJN43Hw40
      MIvjYBunOy9P3ah0kgCk7gW0oKlYHxugv8pZVHMwU1HFIdwYvlGd09XHFDyj9tul
      eX8zaVwaNeLUrMdJN5Ct1HX16RpnpaIMwwExzXgsZ01BQcfIcGWGbvBfH2C86klt
      SuG7M6kxk4XgIIlwTSGk7qJlfd4s8PD1fVJNKvJZwXXoQBy4hCrTAgMBAAGjUzBR
      MB0GA1UdDgQWBBRSUKop9QDGmSdLCfzWlBIF5ClNVDAfBgNVHSMEGDAWgBRSUKop
      9QDGmSdLCfzWlBIF5ClNVDAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUA
      A4ICAQAny4QmzvCza0TQUuh7YIxtkBjJoyTSDGmr5W/4AWKsoZJM9QxzWeIAXhWD
      UPH2TfwcNX/ovZiSDQaGduRL67Wk8lbp1MvjACMEtLRjsbnYtGFdhit0fR97B5Y6
      d06Ka/NXgPTJorXx8WSWUp0qaAQcgvhfgF0vnOSB5CbP5RSYE5TuLu6gh+iQTrBI
      Syl+9UaopkbQDRsg+XRfie+kUxQgldUAFvFmu6sM6FTbw0KGkrsOajwpF/Fu5hSV
      Ucov4Lzrrxkok5FzWPkVtMalLZ4Du+ZUYG//10WZg+HdrIwx3m2wxrFIkZaMKxv4
      ZkIMsb6DUPUZqy8qZpMzIqvDzx3iYEWWfBOCJWBjs8/V1mAuUu6TBCKAJpvfX6bU
      hNrCbnrpuxuCCPJnj9sXkBDvl5rcyfshTtKl3NoBrRRDuUHWsJWzsKvBQtwN46vF
      CbF0aXOozihtmmcMpFFeDIj6p/5qlaJtslegtfv2zoztc3e2ituOjqFQ/I5pplvo
      p8EGwCI1xTGF0BTatcSV1+lLNeONhhAtwliV13nPSH1o4yxoZ+xZTZq4+9ylw7dq
      yV3BQM11U6OyAPE1G6EX0PgFvLm25sGTJq9TKXs9yWPRit9vHcOCXSGn8osn4SMg
      Puqpk+3M9xR8XDPJiBjkxcSnt9+EDNwpthTzgUEoyM6dY8nvWA==
      -----END CERTIFICATE-----
    - "$$SCONE::remote_validation_service$$"
  update:
    - NONE

This policy will allow read requests from the creator, a user whose public certificate has hash 1809fafa119b97db77a43562c5241b3db33d21a85516e35ebe0a19bf0e3d29ee, a user whose certificate is specified in the session description and a user whose credential is taken from the secret named remote_validation_service (which may be imported from another session). No one is allowed to update the session description.

Referencing Other Sessions

In some cases it may be necessary to reference other sessions, e.g. when exporting or importing volumes or secrets. This is possible using the given session ID format:

<session name>[:<session hash>]

Access to/from remote sessions will be verified according to this ID. The hash part is optional.

Examples:

• my_cloud_service
• my_cloud_service:408c03d53e8689062dff5fa21866c173fd482351df47767371556bec395241c6