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
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.
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
updatecan 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 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 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-keyshows 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
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.
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
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: update: $$SCONE::external_update_policy$$
Ensure referenced secrets are valid and stay valid throughout the session's lifetime. Otherwise, you may lose access to your session.
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.
Controlling access to a session with a single credential is insufficient for multi-stakeholder computations. The governance system allows multi-credential access control using
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_member2, as well as at least 2 of the 3
Governance rules can be used in the
create_sessions access policies but not in the
read access policy.
require-at-least-X rules are designed to be used with
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.