Skip to content

Create your own Namespace

Public CAS scone-cas.cf is a shared infrastructure. To isolate policies, CAS supports namespaces. Actually, namespaces can be nested. The creator of a namespace can control who can create policies in this namespace, who can read the namespace and who can update the namespace. In other words, the creator gets full control of this namespace. Nobody, no system admin, no admin of the CAS, can get access to this namespace - as long as the SCONE CAS runs in production mode.

For our experiments, we create a separate namespace at public CAS scone-cas.cf and use this in the context of this tutorial. Note that scone-cas.cf runs in debug mode, i.e., we need to accept this when attesting scone-cas.cf. Also, scone-cas.cf should only be used for development and testing.

The scone CLI creates a public/private key pair and only this key pair enables us to access this namespace. This key pair is stored in the home directory of the user. For now, we assume that the machine on which the user executes the CLI is trusted. In a later assignment, we will show how to protect this public/private key pair and the configuration information of the scone CLI.

The scone policy language will evolve over time. The version of the policy language should be specified as part of the policy. If we forget to specify the version, right now, an old version of the policy language is selected, i.,e., version "0.2". As soon as version "0.2" is not supported anymore, not specifying a version will result in an error.

In this assignment, you should not specify a version. This will prevent us from actually generating nested policy (- since this was not yet supported in version "0.2"). We do this, to fix this mistake in the next assignments. We will learn how to update a policy or a namespace to a new version "0.3".

Task

Create a script in your favorite scripting language that

  • creates a new namespace
  • ensures that only you can create sessions in this namespace

  • ensures that the name of your namespace is unique

  • checks if it already created a namespace

  • if it was already created, do not recreate it but use the existing namespace

  • ensure that the script is idempotent

  • can be restarted in case its execution was interrupted previously or if it already ran previously

  • store the name of the namespace and the hash value of the policy

  • to ensure that we can find the session later again, and
  • that we can update the session

Background

To ensure that we do not conflict with other users, we can generate a new namespace that starts with a prefix like "my_assignment-" and then append the user name and a random number:

export NS="my_assignment-$USER-$RANDOM"

You can print the name of the namespace as follows:

echo "The name of the namespace is $NS"

You can check if a namespace exists by reading the policy that describes the namespace:

scone session read "$NS"

If the namespace does not yet exist, you could create a minimal policy that might look like this:

name: $NS
version: "0.2"

In a nutshell, this policy specifies a

  • name: in this case is given by environment variable $NS, and
  • version: in this case given "0.2" - which is actually a version that is already deprecated.

An implicit access policy is defined: only the creator - identified by its public key - can read or update this policy. In other words, only an entity that knows the private key belonging to the public key can identify itself as the creator.

A policy cannot be deleted. This is to avoid issues that policies can be deleted and later replaced by a brand new policy. One can, however, update policies. We will

  • change the version number, and
  • add some explicit access policy

in a later assignment.

Say, you store this policy in file session.yml, you can then create this policy with the scone session create CLI as follows:

scone session create -e NS="$NS" session.yml

Note that option -e <VAR=VALUE> permits to add or overwrite existing variables in the given session file. We call a file that does contain environment variables like $NS a session template. Only if all environment variables are replaced by values, CAS will this as a syntactically correct policy (a.k.a., a session).

In this example, one could also use the flag --use-env. In this case, the environment variables are defined when the call scone session create is used for variable substitution. Note that option -e has priority of the environment variables: if a variable $NS is defined both in the environment as well as via -e, the value defined by -e is used.

Each policy has a hash value. This hash value is returned when creating or updating the session. This might look like this:

5297ee7bf668836addda1bf89438da43211d049ecb9a42dbfaa7bf9de620698f

Solution

A solution for this task for bash is available in assignment 2](https://github.com/scontain/Exercise/tree/main/Exercise2).

Screencast

Troubleshooting

  • Please have a look at the troubleshooting hints from the previous assignments. If you experience any additional issues, please let us know via email. We will add the issue and a proposed solution to this troubleshooting section.