diff --git a/Writerside/e.tree b/Writerside/e.tree index 3364115..fe6828a 100644 --- a/Writerside/e.tree +++ b/Writerside/e.tree @@ -23,7 +23,7 @@ - + @@ -80,6 +80,7 @@ + diff --git a/Writerside/topics/Contributors.md b/Writerside/topics/Contributors.md index df642a3..384621a 100644 --- a/Writerside/topics/Contributors.md +++ b/Writerside/topics/Contributors.md @@ -8,6 +8,7 @@ We thank all the contributors who have helped in the development of this project - [Jordan Claspell](https://github.com/claspell) - [Konstantin](https://github.com/titi7454) - [LaTanya Donaldson](https://github.com/ldonald067) +- [Lauri Heino](https://github.com/melodicore) - [Sam Gammon](https://github.com/sgammon) - [Sayyid Yofa](https://github.com/sayyidyofa) - [Sebastian Schuberth](https://github.com/sschuberth) diff --git a/Writerside/topics/Secrets.md b/Writerside/topics/Secrets.md new file mode 100644 index 0000000..b3fc73f --- /dev/null +++ b/Writerside/topics/Secrets.md @@ -0,0 +1,261 @@ +# Secrets + +Elide has built-in secret management with multi-user remote management and escrow. Secrets are always encrypted when +stored or transferred, and will only ever be plaintext in memory at runtime. The remote may currently either be within +project sources or in a separate private GitHub repository, but support for other storage providers may be coming +depending on interest. + +## Concepts + +There are a couple of core concepts to understand in how Elide handles secrets. + +- Secret: + - A piece of secret data + - May be text or binary + - May be retrieved in all guest languages in Elide runtime + - Text secrets may be registered as environment variables that are only visible within the runtime +- Local files: + - Files that are stored locally on a single machine + - Should never be shared +- Remote files: + - Files that are shared between all users + - May exist locally if stored with project sources +- Secret profile: + - A container of an arbitrary number of secrets + - Encrypted with a randomly generated key + +## Local secret management + +This part of the guide covers the local part of managing secrets in Elide. + +### Initialization + +To start, run `elide secrets`. This is an interactive command line utility for managing secrets. On first launch, you +get the following prompts: + +1. How do you want to encrypt locally stored secrets? + - Passphrase: Encrypt local secrets with a passphrase + - GPG: Encrypt local secrets with GnuPG. Please note that this method expects to find the `gpg` binary in `PATH`. Only private keys in your default gpg configuration will be available +2. Do you want to initialize a new project or pull an existing project? + - Initialize a new project: Select this option for now + - Pull an existing project: Multi-user management will be covered later in this guide +3. What is the name of your project? + - Enter the project name. This defaults to the project name in `elide.pkl`, or the name of the current directory if +no manifest is present + +After this, you are presented with the main menu. + +### Main menu + +The main menu has the following options: + +- Create a new profile +- List profiles +- Select a profile to edit +- Remove a profile +- Change encryption details +- Pull changes from remote +- Push changes to remote +- Manage remote as a superuser +- Exit secret management + +Most of these options are self-explanatory. Remote operations are covered later in this guide. + +### Editing a profile + +When selecting the `Select a profile to edit` option, you are asked which profile you want to edit. This list contains +all existing profiles, as well as `Local secrets`. This last option allows you to edit the internal secrets, which can +at worst break the secrets setup and render some secrets irretrievable. Regardless which option you choose, you are +presented with the following options: + +- Create a secret +- List secrets +- Update a secret +- Remove a secret +- Reveal a secret +- Write changes and go to main menu +- Go to the main menu without writing changes + +When creating a secret, you can choose whether the secret should be text or binary data. When creating a text secret, +you can also choose to make it an environment variable. These environment variables are exposed to the Elide runtime. +When creating a binary secret, you are asked for an absolute path to a file containing the secret data. + +### Changing encryption details + +The `Change encryption details` option is for changing your personal encryption details. When selecting this option, +you are asked the same questions as in step 1 of [initialization](#initialization), asking for encryption mode. This is +useful if you want to change your passphrase, or if your GnuPG key has been revoked or expired. + +## Using secrets + +All guest languages have access to a new module called `secrets`, which has one function, `get()`, that takes in a +single argument that must be a string. But to use these, secrets must be first initialized for runtime. To make this +happen, please follow these steps: + +1. If you have just one secret profile, you can skip this step. But with multiple profiles, one of them must be + selected. This can be done by adding the following lines to `elide.pkl`: + ``` + secrets { + profile = "profileName" + } + ``` + The profile can also be selected with the environment variable `ELIDE_SECRETS_PROFILE`. +2. Secrets must be decrypted for use. If you use passphrase encryption, you may provide the passphrase with the + `ELIDE_SECRETS_PASSPHRASE` environment variable. If you use GnuPG encryption, the `gpg` binary may ask for + authentication interactively while blocking Elide initialization, depending on how you have set it up on your system. + +After following these steps, you may call secrets from guest languages. Currently, implementation exists for JavaScript +and Python. For example: + +- Javascript: + ```javascript + const secrets = require('secrets'); + let token = secrets.get('appToken'); + ``` +- Python: + ```python + from elide import secrets + token = secrets.get('appToken') + ``` + +## Remote secret management + +Remote secret management is meant for teams to collaborate with secrets, while only revealing the necessary secrets to +a developer. For this system, there are two levels of access. + +- Superuser: + + A superuser is someone who has access to all secrets and delegates access to normal users. Superuser access is + protected with the same encryption modes as local secrets, passphrase and GnuPG. + +- Regular user: + + A regular user is someone who has access to a subset of secrets, specifically one or more secret profiles. The + superuser allocates one or more access files that are each encrypted with either of the encryption modes. + +### Remote secret providers + +The first time you are doing any remote operation, you are asked where to access remote secrets. Currently, two remote +secret providers are available, `project` and `github`. + +- Project: + + Project secrets are stored within a project's sources. When selecting this option, you are asked for a path relative + to the root directory of your project. + +- GitHub: + + Project secrets are stored in a separate, private GitHub repository. When selecting this option, you are asked for a + GitHub repository identity and a personal access token. + + +> The remote secret provider, project remote path and GitHub repository can also be defined in `elide.pkl`: +> ``` +> secrets { +> remote = "project" /// or "github" +> project { +> path = ".path-to-secrets" +> } +> /// or +> github { +> repository = "organization/repository" +> } +> } +> ``` +> {style="note"} + +## Remote secret management as a regular user + +To use secrets as a regular user, you must select the `Pull an existing project` option when first running +`elide secrets`. If you have already initialized secrets, you can reset by moving or deleting the `.elide-secrets` +directory from your project root. + +After selecting a remote secret provider as described above, you are asked if you want to pull as a superuser. Selecting +`No` then asks you for an access file to import. Select an access file and provide the credentials if necessary, and you +are done. You can now use all the secret profiles listed in the access file. In the main menu, you can now use the +option `Pull changes from remote` to update your local secrets, and `Push changes to remote` to update the remote +secrets. With GitHub remotes, your access token must have write permissions to push changes. + +## Remote secret management as a superuser + +To manage remote secrets as a superuser, select the `Manage remote as a superuser` option in the main menu. You are +asked for credentials, and if your local secrets and remote secrets are not identical, you are asked which changes to +overwrite locally. You are then brought to the remote management menu. + +### Remote management menu + +The remote management menu has the following options: + +- Create an access file +- List access files +- Select an access file +- Remove an access file +- Regenerate profile keys +- Delete a profile +- Restore a deleted profile +- Push changes to remote and go to the main menu +- Go to the main menu without pushing changes + +Like with the main menu, most of these options are self-explanatory. + +> Deleting a profile deletes it from local and remote +> secrets, as well as all access files. You can only restore a deleted profile if you deleted it within the same remote +> management session. As soon as you return to the main menu, you can no longer restore deleted profiles. +> {style="warning"} + +### Editing an access file + +When selecting the `Select an access file` option, you are asked which access file to edit. You are then presented with +the following options: + +- Add a profile to the access file +- List profiles in the access file +- Remove a profile from the access file +- Change encryption details +- Return to the remote management menu + +### Regenerating profile keys + +If a profile's secret key becomes compromised, it is vital to change that key so that any new secrets cannot be +decrypted by third parties with access to the remote files. The `Regenerate profile keys` option asks you to select one +or more profiles to rekey, and then regenerates their keys. This option does not change any access file credentials. + +## Non-interactive remote secrets + +Sometimes you have to access secrets without any interactive access. For these purposes, Elide secrets provides the flag +`elide secrets -n` or `elide secrets --non-interactive`. Running this command has only one purpose: Pull a single +profile from a remote and initialize it to be used with the runtime. To do this, it requires some extra options that are +normally optional. + +In `elide.pkl`, you must specify the profile name, remote type and remote options: + +``` +secrets { + profile = "profileName" + remote = "project" /// or "github" + project { + path = ".path-to-secrets" + } + /// or + github { + repository = "organization/repository" + } +} +``` + +In addition, you need to define some environment variables: + +- `ELIDE_SECRETS_PASSPHRASE` to specify a passphrase for local encryption. This variable must also be provided to the + runtime. +- `ELIDE_SECRETS_PROFILE` to override the profile specified in `elide.pkl`. If used, this variable must also be provided + to the runtime. +- `ELIDE_SECRETS_ACCESS` to specify the name of an access file. This access file must contain the profile specified in + `elide.pkl` or the above variable. +- `ELIDE_SECRETS_ACCESS_PASSPHRASE` to specify the passphrase of the access file. If the access file uses GnuPG, this + variable is not necessary, but GnuPG may need some additional configuration to function non-interactively. +- `ELIDE_SECRETS_GITHUB_TOKEN` to specify the GitHub access token. This variable is not necessary if `project` remote is + used. + +> The environment variables `ELIDE_SECRETS_PASSPHRASE`, `ELIDE_SECRETS_PROFILE` and `ELIDE_SECRETS_GITHUB_TOKEN` can +> also be used with interactive secrets. +> {style="note"} \ No newline at end of file