SCONE Session Language (v0.3)
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
Changes since version 0.2
- The format by which other sessions are referenced for export/import purposes has changed (see Referencing Other Sessions)
- Secrets can now be exported/imported to/from sessions located on another CAS
- Certificates can now be specified as explicit values for
x509secrets now require a
private-keysecret (unless imported or given an explicit value). This allows more fine-grained export rules (exporting only the certificate, but not the private key) and issuing multiple certificates using the same key
x509secrets have new parameters:
- Access Control Policies now use certificate keys instead of entire certificates - certificate hashes have been replaced by certificate key hashes
Session Description Hash
Each session description has a unique hash value, in short just
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.
This document describes version 0.3.
version field, version 0.1 is assumed, make sure to include the field in all session descriptions in order to use version 0.3.
Every session description has to provide a
session name, or short just
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.
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
Providing a session name is mandatory.
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.
The value has to be 32 hex encoded bytes.
When creating a session, no predecessor session exists and hence no
predecessor key is permitted.
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: /
To be able to identify a service, every service has to have a
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.
Providing a service name is mandatory.
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.
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 is split at whitespace characters. If spaces should be preserved for an argument, either quote the argument (with single or double quotes):
command: mysql -e "show databases;"
or use a list instead:
command: ["mysql", "-e", "show databases;"]
Command arguments have to be C-String compatible, i.e., they are not allowed to contain a NULL byte.
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
- 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
mrenclave, a session description can also limit the set of permitted
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
Changing the pwd to
/plaintext/ before the writing would lead it to write the private key to
To prevent this kind of manipulation the pwd of a SCONE service has to be specified explicitly in the session description.
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.
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 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.
The service-level attestation configuration depends on the session's attestation security settings. If attestation has been disabled for the whole session, then the following sections do not apply.
Measurement-based attestation gives access to service secrets based on the enclave measurement value, abbreviated as
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_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:
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.
- The enclave measurement value (
mrenclave) has to be a sequence of 32 hex encoded bytes.
Platform-based attestation gives access to services that are deployed on a specific platform. This is not sufficiently secure on its own to prevent program manipulation! Thus, platform-based attestation should always be combined with the measurement-based attestation.
platform identity is the public key of the SCONE Quoting Enclave (SCONE QE), which is part of the SCONE Local Attestation Service (LAS).
The SCONE QE will have a unique public key on each platform. Platforms that are allowed to get access to the configuration can be specified as follows:
Platform-based attestation requires the SCONE attestation scheme, which is used by default.
The platform identity has to be a sequence of 32 hex-encoded bytes (i.e., 64 characters).
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.
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:
binary, service leaf and intermediate certificates.
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
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 is given, a default length of 20 will be used.
secrets: - name: my_generate_ascii_secret kind: ascii size: 12
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_generated_binary_secret kind: binary size: 32 - name: my_explicit_binary_secret kind: binary value: DEADBEEF
Private keys are required when generating X.509 certificates (refer to the next section). Possession of a certificate's private key is necessary in order to sign other certificates or use them as e.g. TLS server or client certificates.
Defining an automatically generated private key is simple:
secrets: - name: my_tls_server_private_key kind: private-key
Generated private keys use the NIST P-256 elliptic curve.
Alternatively, a PEM-encoded PKCS#8 P-256 EC private key may also be specified explicitly:
secrets: - name: my_tls_server_private_key kind: private-key value: | -----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY-----
Private keys are accessible in PEM-encoded PKCS#8 format.
CAS is able to generate and manage X.509v3 certificates, making it easy to construct a Public Key Infrastructure (PKI).
There are two kinds of X.509 certificates that CAS supports: End-entity and Certification Authority (CA) certificates.
Their main difference is in their capability to sign other certificates.
End-entity certificates are indicated by kind
x509, CA certificates by
Additional parameters can be specified for certificates:
private_key: Unless imported or given an explicit value, each certificate requires a private key, referencing another
issuer: Optional reference to another
x509-cacertificate which signs this certificate. If omitted, generated certificates will be self-signed. Note that access to the issuer's private key is required for signing unless an explicit certificate
common_name: An optional certificate common name. If omitted, the first
dnsname (see below) will be used as the common name. If no DNS name has been specified, the secret's
namewill be used as the common name.
endpoint: Optional, must be either
clientwhen specified. When specified, an Extended Key Usage (EKU) extension will be added to the generated certificate. If omitted, no EKU extension will be added. Only applicable to end-entity certificates.
dns: Optional DNS name or list of DNS names that will be included in the Subject Alternative Name (SAN) extension of the generated certificate. If omitted, no SAN extension will be added. Only applicable to end-entity certificates. Cannot be used when the certificate has a
valid_for: Optional duration (e.g.:
59d) for which generated certificates are valid. Certificates will automatically be re-generated before they expire. If omitted, generated certificates stay valid for a virtually unlimited amount of time. Not applicable to imported certificates or certificates with an explicit
secrets: - name: my_ca_certificate kind: x509-ca private_key: my_ca_private_key common_name: "My own CA" - name: my_server_certificate kind: x509 private_key: my_server_certificate_private_key issuer: my_ca_certificate common_name: "example.com" valid_for: 90 days endpoint: server dns: - example.com - db.example.com - "*.api.example.com"
By default, certificates will be generated by CAS, but they can also be given an explicit PEM-encoded value instead:
secrets: - name: my_server_certificate kind: x509 value: | -----BEGIN CERTIFICATE----- MIIB0TCCAXigAwIBAgIUX4hfQWl+PKcrmOFW8phCO1vtQpUwCgYIKoZIzj0EAwIw HzEdMBsGA1UEAwwUVGVzdCBJbnRlcm1lZGlhdGUgQ0EwIBcNMjAwNTA2MTQ1NTAx WhgPMzAxOTA5MDcxNDU1MDFaMBYxFDASBgNVBAMMC2V4YW1wbGUuY29tMFkwEwYH KoZIzj0CAQYIKoZIzj0DAQcDQgAE1gqmACizRH9ENwun/rkmqoCjxf6NPJNHTpYg y8D5UOy5HNZXSi6ZNNL1x89d6UZfrYfDrf/PwH5LOhrgfkm42aOBmDCBlTAdBgNV HQ4EFgQUw3LfMbqwEJJRr5v7itg4A5jR0ngwHwYDVR0jBBgwFoAUHgrspKzSFC8r 0/ygrsQIGA+Ft6MwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMB BggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMBYGA1UdEQQPMA2CC2V4YW1wbGUuY29t MAoGCCqGSM49BAMCA0cAMEQCIAC7fWVRBG3mBzfyKf/WidYVL9IcAOdYsElgHTKb 5h5HAiBlXklXq2lXo3srdQNJ4I8QJwWMYLIZUUw7fmWKOaireg== -----END CERTIFICATE-----
Certificates differ from other secrets in terms of access.
Please see the
Secret Access chapter for the details.
Certificate Verification Failure
If the verification of the generated certificate fails, this is often an indication that the
common_name or the
dns names (Subject Alternative Name) are not matching the DNS name of the service
that use this certificate.
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
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
To inject secrets into a service's environment the session description could contain this:
[...] environment: FILE_ENCRYPTION_KEY: "$$SCONE::MY_SERVICES_ENCRYPTION_SECRET$$" [...]
Secrets referred to (
MY_SERVICES_ENCRYPTION_SECRET in the above example) have to be either defined in the
secrets section of the session description or imported from another session.
Binary Secret Values
By default, when using
$$SCONE::my_secret$$, binary secrets are injected in binary form. When working with environment variables or command line arguments, a hexadecimal representation may be preferable:
Certificate secrets may be composed of multiple values: First off the certificate itself, optionally (if accessible) their private key, and lastly they may have an attached certificate chain.
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, with the root CA certificate first and the certificate itself last (included). Root CA certificate and topmost intermediate CA certificates may be omitted if they are not known or the certificate is self-signed.
Note that the
.key suffix is not guaranteed to exist, it is for instance not available when importing certificates from another session which does not grant access to the certificates' private keys.
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:
[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$$
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.
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_key kind: private-key export: session: database_client - name: database_access_certificate kind: x509 private_key: database_access_key export: session: database_client
The secret owner might also specify multiple receiving sessions at once:
name: database_operator secrets: - name: database_access_key kind: private-key export: - session: database_client - session: another_client - name: database_access_certificate kind: x509 private_key: database_access_key export: - session: database_client - session: another_client
Furthermore, the export might be restricted to certain instances of the importing session. For more details, see the concrete SCONE ID 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: session: database_operator secret: database_access_certificate
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.
When importing certificates, the associated
private-key does not have to be imported explicitly - it will be available automatically if the exporting session exports the private key as well.
In very specific cases, secrets may also be made public (exported to anyone without authentication) - this may be useful when, for example, defining certificate key hashes:
name: policy_checker secrets: - name: certificate_hash kind: ascii value: "4sEY84YhUKT7Q7m4qUj2pmQMxFvZK5XpDyJ3QR6mETVRDkyren" 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: session: policy_checker secret: certificate_hash access_policy: read: - "$$SCONE::policy_checker_certificate_hash"
export_public: true, the whole world will be able to see the secret value. Make sure this is your intention.
These secrets may also be queried through the
/v1/values CAS REST API endpoint.
When uploading a new session which has a predecessor session, secret migration takes place. In short: ASCII and binary 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: private-key
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.
Generated private keys and certificates will never be kept, they will always be re-generated when updating a session.
Secret migration also takes place when using a different session description language version (e.g. 0.2 -> 0.3)! For details, see the session secrets migration documentation.
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.
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 (
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.
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: session: another-session
volumes: - name: my_database export: - session: another-session - session: foobar session_hash: 668e9aaba22c7631bbcc89b627d77e53539bcaade9e7c2c08242f56aab272088
The concrete SCONE ID format by which other sessions can be referenced is described in section Referencing Other Sessions. Note that volumes can only be exported to local sessions on the same CAS, not to sessions on a remote CAS.
Similarly, volumes may be imported from another session (in which case fspf key/tag and export list must be omitted):
volumes: - name: their_database import: session: the_exporting_session volume: my_database
When exporting a volume, it is possible to restrict which kind of modifications an importing session is allowed to perform. Section Image Volumes demonstrates how volume access can be restricted for local services; the same is also possible for volume exports by using the
volumes: - name: my_database export: - to: session: foobar session_hash: 668e9aaba22c7631bbcc89b627d77e53539bcaade9e7c2c08242f56aab272088 update_policy: ephemeral
Note that the SCONE ID (
session_hash) needed to be moved to a new
update_policy can have any of the following values:
ephemeral: Importing sessions may only use the
ephemeralpolicy. This implies that they are not allowed to alter the volume's state on the CAS (please read Image Volumes for further explanation). Any tag policy specified by the importing session is ignored.
rollback_protected: This is the default setting if
update_policyis omitted. Importing sessions can use either a
ephemeralpolicy at their discretion.
no_rollback_protection: Importing sessions are allowed to use a
no_rollback_protectionpolicy at their discretion. This option is dangerous, as it also allows third parties to perform rollbacks unnoticed. It should not be necessary for most use cases.
images keyword allows specifying images usable by services (see section Service Description). Each image has an arbitrary but unique
images: - name: my_image
Images may define access to volumes, by referencing a previously declared volume's
name and giving it a mount point (
volumes: - name: my_database images: - name: my_image volumes: - name: my_database path: /media/database
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.
By default, volumes are rollback-protected: Attempting to restore an old volume state and letting a service read files from or write files to this old state will be detected and prevented. In specific cases, however, this may not be the desired behavior. The
update_policy key can be used to change it:
volumes: - name: my_database images: - name: my_image volumes: - name: my_database path: /media/database update_policy: no_rollback_protection
The following values are possible as a volume
rollback_protected: This is the default setting if
update_policyis omitted. Services are allowed to alter the volume state, any rollback will be detected and lead to an error upon access. This ensures a coherent, linear history of volume changes.
ephemeral: Any changes done to the volume state will be ignored by CAS. This can be useful when a volume is supposed to remain in a specific state - an initialization service could use an image with volume
update_policy: rollback_protectedto prepare the volume, and all other services can use
update_policy: ephemeralin order to ignore further modifications. Note that this does not prevent services from modifying files and directories in the volume's path! This will still work as long as the service is running. Once it is restarted, however, CAS will detect the modification and refuse any access to the modified volume. Therefore, if you expect services to make changes to the volume, it is a good idea to back up the initialized volume, and restore this backup once the service is stopped. This ensures that new instances of the service are able to access the volume in its expected state.
no_rollback_protection: Services are allowed to alter the volume's state and rollback prevention checks are disabled. This option is dangerous, as it also allows third parties to perform rollbacks unnoticed. It should not be necessary for most use cases.
When using an imported volume, the exporting session may have applied restrictions on the volume's
Attempting to use an unauthorized
update_policy will lead to errors upon volume access.
For details, please refer to section Volume Sharing.
Secret Injection 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.
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. The
access_policy keyword allows specifying 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
Granting permission to a certain entity to perform one of these operations involves adding their client certificate public key to the list of authorized entities.
A certificate with this key shall be used when establishing a connection to CAS (see API Documentation, Authentication section). TLS ensures that the client is in possession of the corresponding private key.
CAS uses key-based authentication instead of whole certificate authentication to ensure that certificates can be renewed without problems - otherwise, users could be locked out of the session when their certificate expires.
When using the scone CLI, the user certificate can be shown by running
scone self show.
Beside public certificates, the following values can be used:
- Public key hash of a certificate. This hash can be calculated by using the SCONE CLI:
scone self showshows the hash of the CLI client identity,
scone cert show-key-hash "path_to_certificate_file_in_pem_format"shows the key hash for any certificate file. A valid hash looks similar to:
CREATORkeyword: permit access to the creator of the policy: this is the public key of the TLS client certificate used when creating this session
ANYkeyword: permit access to any entity. If
ANYis specified, there must be no other entries in the list for this operation
NONEkeyword: deny all requests for a particular operation. If
NONEis 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 certificate key 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
.crtafter 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, but an error message will be shown on unsuccessful authentication attempts.
By default, the access policy is defined as follows:
access_policy: read: - CREATOR update: - CREATOR
Default values will be used for operations not explicitly specified in a session description.
access_policy: read: - CREATOR - 3s1pm8W6Be6cxvAQRbRP5YXd9YuERAr7KswN97uGtoPkRW87x1 - | -----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 TLS client certificate has a public key hash
3s1pm8W6Be6cxvAQRbRP5YXd9YuERAr7KswN97uGtoPkRW87x1, a user whose TLS client certificate has a public key similar to the one of the certificate 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.
The services' security directly depends on CAS' ability to verify that a service process has not been manipulated (referred to as attestation), as described in the service attestation section. CAS ships with secure defaults, and only allows hardware-attested services running on trustworthy platforms in secure production-mode enclaves.
Tolerating hardware attestation issues
Sometimes it may be necessary to relax the secure defaults, for instance, when:
- Services should run in a testing environment for debugging purposes
- A trade-off is being made between security and performance, like enabling Hyper-Threading (which opens an Information Disclosure Side Channel)
- A platform with known security vulnerabilities is used in a testing environment
security: attestation: tolerate: [debug-mode, hyperthreading]
tolerate is an array which can hold the following variants:
debug-modeenclaves allow introspection with a debugger. This disables enclave protection, all secrets can be extracted.
hyperthreading: Enabled Hyper-Threading opens a Microarchitectural Data Sampling Information Disclosure Side Channel on Intel SGX platforms. If the performance penalty can be tolerated, disabling Hyper-Threading instead of ignoring the issue may be viable. See https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html
insecure-igpu: An enabled integrated GPU could be exploited to disclose information on Intel SGX platforms. If not required for operation, disable the IGPU instead of tolerating this issue. See https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00219.html
software-hardening-needed: The service program needs to be re-compiled with different compiler settings to protect against exploits. This is a category for a collection of Intel SGX advisories, which need to be specified separately (see below).
insecure-configuration: The platform needs to be reconfigured to protect against certain kinds of attacks. This is a category for a collection of Intel SGX advisories, which need to be specified separately (see below).
outdated-tcb: The Trusted Computing Base (TCB) of the platform, i.e. firmware or microcode, needs to be updated due to security flaws. This is a category for a collection of Intel SGX advisories, which need to be specified separately (see below).
When running a service on a platform that is affected by one of the above problems, attestation will fail with an error, unless they have been specified in the
tolerate list. The error message will contain instructions on how to change attestation security settings in order to ignore the specific problems.
Instead of ignoring platform security issues, solving them should always be preferred. Often, this involves updating the platform's firmware or CPU microcode. Sometimes, it can be necessary to change BIOS/UEFI settings or recompile the service with different settings. The error message as well as linked Intel advisories contain more details.
Displayed attestation error messages are not authenticated, and may be forged by a MitM attacker. It is advisable to critically review the suggested configuration changes as well as Intel advisories.
Intel will release advisories when becoming aware of new security issues with SGX-enabled processors. Some of the problems listed in these advisories are encountered more frequently, in which case SCONE/CAS provide shortcuts to ignore them (like
hyperthreading). Others may be more severe or very recent. In order to ignore them, they and their associated category (
outdated-tcb) need to be specified explicitly. Example:
security: attestation: tolerate: [outdated-tcb] ignore_advisories: [INTEL-SA-00161, INTEL-SA-00270]
debug-mode, all advisories can be ignored by using a wildcard, simplifying the workflow in testing environments:
security: attestation: tolerate: [debug-mode, outdated-tcb] ignore_advisories: "*"
As this silently ignores newly released platform advisories too, wildcards cannot be used in (non-debug) production mode.
Trusted SCONE Quoting Enclaves
By default, the system uses the SCONE attestation scheme. This scheme is built around a separate quoting enclave (QE), into which trust has to be established. This is done automatically using EPID-based attestation for a set of known trustworthy QE measurements embedded into the CAS software.
If EPID-based attestation is not available, or you want to use custom QEs, the QE public keys can be manually specified as trustworthy:
security: attestation: trusted_scone_qe_pubkeys: ["E37F149AE30896E314A2859874C5A9C7803FB3187B99F5D08E526B1C0396507C"]
The QE public key can be found in the log output of the Local Attestation Service (LAS). Specified keys are an additional trust anchor, and do not replace the trusted built-in QE measurements. To trust the given keys exclusively, additionally enable platform-based attestation for individual services.
Attestation can be completely disabled:
security: attestation: mode: none # Default mode is 'hardware'
This may be useful in testing environments where no hardware-based attestation is available.
Disabling attestation implies that there is no service authentication being performed at all. Everybody with access to CAS can access all secrets of all of this session's services.
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 by using a SCONE ID. The following sections describe the format and content of this ID.
Local CAS Sessions
Referencing another session on the same CAS is simple:
session: <session name> - e.g.
Note that, depending on the context, you may also have to supply a secret, volume or service name, e.g.:
session: my-database secret: db-encryption-key
By using this simple form, you trust the session's owner, and accept that their session configuration may change over time. If you want to trust a specific session configuration instead, you have to additionally specify a session hash:
session: <session name> session_hash: <session hash-key>
session: my-database session_hash: a51c14dd7029d2ef54a50a9e26efcdd37c4971b5b62cb6d244c9216f80b6eadf
Exporting/Importing elements to/from the other session will be prevented by the CAS when the currently active session does not match the specified hash. Note that, in this case, your own session may cease working when importing secrets or volumes from another session whose hash has changed, requiring you to update the session.
Sessions on another CAS
Referencing sessions on another CAS requires more information - the remote CAS' address and a key to authenticate it:
cas_url: <CAS address> cas_key: <CAS key hash> session: <session name>
cas_url: cas.example.com cas_key: 46YyxrywJ8PFRruWX8YLxa9q4axxYJgTbA81tv7NBcJfn43DQt session: company-storage
cas_key is used for authentication and ensures that exports/imports will only be performed to/from the correct CAS.
It is of utmost importance to specify a verified, correct key.
When a CAS was attested using the CLI, you can query its verified key by using
scone cas show-identification -c.
Similarly, when attesting a CAS, you can supply the key received from another session's owner by using
scone cas attest -c <CAS key hash>.
cas_key, you trust the remote CAS' owner and allow them to perform software updates without further confirmation.
Most of the time, this is an adequate solution.
In specific cases, when trusting the remote CAS' owner is not an option, it may be necessary to pin a specific CAS software revision instead.
This may be done by using the
cas_software_key instead of a
cas_url: <CAS address> cas_software_key: <CAS key hash> session: <session name>
cas_url: cas.example.com cas_software_key: 3AC5RSbL73aVVf98m2UMTN2BFsQv6eQufi5BGBxrG8awxP4ygQ session: company-storage
In this case, exporting/importing elements to/from the other session will be prevented by the local CAS when the software of the remote CAS changes.
The same limitations as specified for the usage of a
session_hash apply here as well.
The software key can be retrieved or specified on the CLI by using
scone cas show-identification -s and
scone cas attest -s <CAS software key hash> respectively.
URL short form
Instead of using YAML syntax, you can also fit all SCONE ID fields on a single line, forming a SCONE URL.
cas_url: cas.example.com cas_software_key: 3AC5RSbL73aVVf98m2UMTN2BFsQv6eQufi5BGBxrG8awxP4ygQ session: company-storage
can also be written as
This may be useful when referencing the same CAS multiple times, as the CAS URL and keys can be extracted into a common variable, example:
export: - $OTHER_CAS,session=A - $OTHER_CAS,session=B - $OTHER_CAS,session=C
For replacing the variable with a concrete value, please refer to the SCONE CLI documentation.
The same format can also be used when referencing sessions on the local CAS. Simply omit the host and keys (but notice the leading slash