Skip to content

Governance

Many applications include multiple stakeholders, which together need to govern the application. In some domains, a single entity is not trusted to make unilateral decisions. For example, a single administrator should not be able to decide which application should get access to which secrets. Such decisions have to be made as a group consisting of representatives of the stakeholders.

SCONE CAS supports advanced governance: Policy creations and changes must be approved by a policy board. The policy board can consist of humans as well as programs. We refer to these programs as automated policy checkers. The policy board votes by signing policy changes. Policy creations/changes are only accepted if a sufficient set of signatures is on the policy: the policy declares which signatures are sufficient.

Declaring who needs to sign a policy can be centralized: the governance rules can be imported from other policies (aka as import of policy fragments). This enables us to

Background

Each security policy has integrated access control. The policy declares who can access the policy. SCONE supports governance by defining which stakeholders must agree to change a policy or create new policies.

Access Control

Any operation on a session description requires permission. If the entity requesting a specific 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 session description - without the secrets generated by CAS
  • update: permit to update the session
  • create_sessions: Create new sessions in the namespace of this session. If omitted, all entities listed under update can create sessions.

Granting permission to a specific 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 to establish a CAS connection. TLS ensures that the client has 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 certificates expire. 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:

  • Public key hash of a certificate. This hash can be calculated using the SCONE CLI: scone self show shows 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 3s1pm8W6Be6cxvAQRbRP5YXd9YuERAr7KswN97uGtoPkRW87x1.
  • 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 certificate key hash (ascii), or a certificate (x509) as defined above. It is possible to use explicit secrets, generated secrets, and imported secrets. When referencing X.509 certificates, do not specify a format suffix. It will be ignored if the mentioned secret does not exist, cannot be read, or has an incompatible value. Still, an error message will be shown on unsuccessful authentication attempts.
  • signer: <public key>: Public key of a session signer. Signing sessions are an alternative to TLS client certificates during session upload. scone self show-session-signing-key shows the CLI signer identity. The public key is Base58check-encoded (BITCOIN alphabet). The Base58check version must be 10, and the encoded key must be an Ed25519 key. A valid public key looks similar to: LtLcbPVddnCkH36ZcRdgYsw4H8xDbYaFZfuefkDc25uq2qdjmM. Note that signers are not supported in the read policy.
  • require-all: or require-at-least-X:

By default, the access policy is defined as follows:

access_policy:
  read:
   - CREATOR
  update:
   - CREATOR
  create_sessions:
    <same as update>

Default values will be used for operations not explicitly specified in a session description.

Example policy:

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:
    - signer: LtLcbPVddnCkH36ZcRdgYsw4H8xDbYaFZfuefkDc25uq2qdjmM
  create_sessions:
    - NONE

This policy will allow reading 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 certificates 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). The session may only be updated if successors are signed by the given signer identity LtLcbPVddnCkH36ZcRdgYsw4H8xDbYaFZfuefkDc25uq2qdjmM. No one is allowed to create sessions in its namespace.

Individual sections or the entire access_policy can be replaced with variables, too:

access_policy: $$SCONE::external_policy$$
access_policy:
  update: $$SCONE::external_update_policy$$

Warning

Ensure referenced secrets are valid and stay valid throughout the session's lifetime. Otherwise, you may lose access to your session.

Note

When an imported access policy (fragment) contains CREATOR, the reference is evaluated in the context of the importing session, i.e., the creator of the importing session is authorized.

Policy Board

Controlling access to a session with a single credential is insufficient for multi-stakeholder computations. The governance system allows multi-credential access control using require-all and require-at-least-X rules.

Example:

access_policy:
  read: NONE
  update:
    require-all:
      - require-at-least-2:
          - signer: $voter1
          - signer: $voter2
          - signer: $voter3
      - require-all:
          - signer: $veto_member1
          - signer: $veto_member2

The above example requires an update to a session to be signed by both $veto_member1 and $veto_member2, as well as at least 2 of the 3 $voters.

Governance rules can be used in the update and create_sessions access policies but not in the read access policy.

Note

require-all and require-at-least-X rules are designed to be used with signers. While it is possible to specify certificates or certificate key hashes, remember that a session can be created using precisely one TLS client certificate or one or more signatures. Therefore, it does not make sense to require more than one certificate at a time.

Rules can be arbitrarily deeply nested. Extended example:

access_policy:
  read: NONE
  update:
    require-at-least-1:
      - signer: $owner
      - require-all:
          - require-at-least-2:
              - signer: $voter1
              - signer: $voter2
              - signer: $voter3
          - require-all:
              - signer: $veto_member1
              - signer: $veto_member2

This example works the same as the previous one but allows the $owner to overrule all other members.