summon

summon

cyberark.github.io/summon

summon is a command-line tool to make working with secrets easier.

It provides an interface for

• Reading a secrets.yml file
• Fetching secrets from a trusted store
• Exporting secret values to a sub-process environment
• Writing secrets to files in various formats (push-to-file)

Install

Note installing summon alone is not sufficient; you need to also install a provider of your choice before it's ready for use.

Pre-built binaries and packages are available from GitHub releases here.

Using Summon with Conjur Open Source

Are you using this project with Conjur Open Source? Then we strongly recommend choosing the version of this project to use from the latest Conjur OSS suite release. Conjur maintainers perform additional testing on the suite release versions to ensure compatibility. When possible, upgrade your Conjur version to match the latest suite release; when using integrations, choose the latest suite release that matches your Conjur version. For any questions, please contact us on Discourse.

Homebrew

brew tap cyberark/tools
brew install summon

Linux (Debian and Red Hat flavors)

deb and rpm files are attached to new releases. These can be installed with dpkg -i summon_v*.deb and rpm -ivh summon_v*.rpm, respectively.

Auto Install

Note Check the release notes and select an appropriate release to ensure support for your version of CyberArk Secrets Manager.

Use the auto-install script. This will install the latest version of summon. The script requires sudo to place summon in /usr/local/bin.

curl -sSL https://raw.githubusercontent.com/cyberark/summon/main/install.sh | bash

Manual Install

Otherwise, download the latest release and extract it to /usr/local/bin/summon.

Usage

By default, summon will look for secrets.yml in the directory it is called from and export the secret values to the environment of the command it wraps.

Example

You want to run a script that requires AWS keys to list your EC2 instances.

Define your keys in a secrets.yml file

AWS_ACCESS_KEY_ID: !var aws/iam/user/robot/access_key_id
AWS_SECRET_ACCESS_KEY: !var aws/iam/user/robot/secret_access_key

The script uses the Python library boto, which looks for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the environment.

import boto
botoEC2 = boto.connect_ec2()
print(botoEC2.get_all_instances())

Wrap the Python script in summon:

summon python listEC2.py

python listEC2.py is the command that summon wraps. Once the Python program exits, the secrets stored in temp files and in the Python process environment are gone.

secrets.yml Flags

Currently, you can define how the value of a variable will be processed using YAML tags. Multiple tags can be defined per variable by spearating them with :. By default, values are resolved as literal values.

• !file: Resolves the variable value, places it into a tempfile, and returns the path to that file.
• !var: Resolves the value as a variable ID from the provider.
• !str: Resolves the value as a literal (default).
• !default='<value>': If the value resolution returns an empty string, use this literal value instead for it.

Examples

# Resolved summon-env string (eg. `production/sentry/api_key`) is sent to the provider
# and the value returned is saved in the variable.
API_KEY: !var $env/sentry/api_key

# Resolved summon-env string (eg. `production/aws/ec2/private_key`) is sent to the provider.
# The returned value is put into a tempfile and the path for that file is saved in the
# variable.
API_KEY_PATH: !file:var $env/aws/ec2/private_key

# Literal value `my content` is saved into a tempfile and the path for that file is saved
# in the variable.
SECRET_DATA: !file my content

# Resolved summon-env string (eg. `production/sentry/api_user`) is sent to the provider.
# The returned value is put into a tempfile. If the value from the provider is an empty
# string then the default value (`admin`) is put into that tempfile. The path to that
# tempfile is saved in the variable.
API_USER: !var:default='admin':file $env/sentry/api_user

Default values

Default values can be set by using the default='yourdefaultvalue' as an addtional tag on the variable:

VARIABLE_WITH_DEFAULT: !var:default='defaultvalue' path/to/variable

Flags

summon supports a number of flags.

• -p, --provider <path-to-provider> specify the path to the provider summon should use.

  If you do not provide Summon with the full path to the provider, Summon will look for providers in the following order:

  • Environment Variable: SUMMON_PROVIDER_PATH
  • /usr/local/lib/summon on Linux / Mac
  • %ProgramW6432%\Cyberark Conjur\Summon\Providers on Windows.
  • ${summon binary dir}/Providers For portable installation
  • ${summon binary dir}/../lib/summon For homebrew installations

• -f <path> specify a location to a secrets.yml file, default 'secrets.yml' in current directory.

• --up searches for secrets.yml going up, starting from the current working directory.

  Stops at the first file found or when the root of the current file system is reached. This allows to be at any directory depth in a project and simply do summon -u <command>.

• -D 'var=value' causes substitution of value to $var.

  You can use the same secrets.yml file for different environments, using -D to substitute variables. This flag can be used multiple times.

  Example

  summon -D ENV=production --yaml 'SQL_PASSWORD: !var env/$ENV/db-password' deploy.sh
  

  Warning: Never embed plaintext secret values in the subsitution string passed to this flag - command-line arguments are exposed in process listings and shell history.

• --yaml <YAML-string> Passes secrets.yml as a literal string.

  This flag is used to pass a literal YAML string to the provider in place of the secrets.yml file (see example above).

  Warning: Never embed plaintext secret values in the YAML string passed to this flag - command-line arguments are exposed in process listings and shell history.

• -i, --ignore <path-to-provider> A secret path for which to ignore provider errors.

  This flag can be useful for when you have secrets that you don't need access to for development. For example API keys for monitoring tools. This flag can be used multiple times.

• -I, --ignore-all A boolean to ignore any missing secret paths.

  This flag can be useful when the underlying system that's going to be using the values implements defaults. For example, when using summon as a bridge to confd.

• -V, --all-provider-versions List of all of the providers in the default path and their versions (if they have the --version tag).

• -v, --version Print the Summon version.

• -d, --debug Enable debug logging.

  When set, summon prints detailed log messages (at DEBUG level) to stderr, including configuration loading, secret fetching progress, and error details. Useful for troubleshooting provider or secrets.yml issues.

• -e, --environment Specify section (environment) to parse from secret YAML.

  This flag specifies which specific environment/section to parse from the secrets YAML file (or string). In addition, it will also enable the usage of a common (or default) section which will be inherited by other sections/environments. In other words, if your secrets.yaml looks something like this:

common:
  DB_USER: db-user
  DB_NAME: db-name
  DB_HOST: db-host.example.com

staging:
  DB_PASS: some_password

production:
  DB_PASS: other_password

Doing something along the lines of: summon -f secrets.yaml -e staging printenv | grep DB_, summon will populate DB_USER, DB_NAME, DB_HOST with values from common and set DB_PASS to some_password.

Note: default is an alias for common section. You can use either one. Also note that when not using named environments, the common section will be ignored.

• -h View help and all flags.

env-file

Using Docker? When you run summon it also exports the variables and values from secrets.yml in VAR=VAL format to a memory-mapped file, its path made available as @SUMMONENVFILE.

You can then pass secrets to your container using Docker's --env-file flag like so:

summon docker run --env-file @SUMMONENVFILE myorg/myimage

This file is created on demand - only when @SUMMONENVFILE appears in the arguments of the command summon is wrapping. This feature is not Docker-specific; if you have another tools that reads variables in VAR=VAL format you can use @SUMMONENVFILE just the same.

Push-to-File

summon.files lets you write resolved secrets directly to files rather than environment variables. Summon fetches each secret via the provider and renders a file from a Go text/template (or a built-in format), then writes the result atomically with the configured permissions. The file will be removed when the summon process exits.

Configuration fields

Supported format: values

Template rendering context

When format: template is used, the following functions and variables are available:

All built-in Go text/template functions (e.g. html, urlquery, printf) are also available.

Example

# secrets.yml
summon.files:
  - path: "./config/db.conf"
    format: template
    permissions: 0640
    overwrite: true
    template: |
      [database]
      host     = {{ secret "DB_HOST" }}
      username = {{ secret "DB_USERNAME" }}
      password = {{ secret "DB_PASSWORD" }}
      api_key  = {{ secret "API_KEY" | b64enc }}
    secrets:
      DB_HOST:     !var app/prod/db-host
      DB_USERNAME: !var app/prod/db-username
      DB_PASSWORD: !var app/prod/db-password
      API_KEY:     !var app/prod/api-key

Running summon -p <provider> cat ./config/db.conf will write config/db.conf with the resolved secrets substituted into the template, followed by outputting its contents to STDOUT, and finally the file will be removed when the summon process exits.

Security considerations

• File cleanup is not guaranteed. Summon removes pushed files when the wrapped process exits normally or is terminated by a signal it can catch. However, if the summon process is forcefully killed (e.g. SIGKILL / kill -9) or the system crashes, the files may remain on disk. You should have a secondary cleanup mechanism (e.g. a startup script, tmpwatch, or an ephemeral filesystem) for environments where this is a concern.
• Use the most restrictive permissions possible. The default file permissions are 0600 (owner read/write only). If your application allows it, keep the default. Avoid overly permissive modes such as 0644 or 0755 which expose secret files to other users on the system.

Fixed tempfile name

There are times when you would like to have certain secrets values available at fixed locations, e.g. /etc/ssl/cert.pem for an SSL certificate. This can be accomplished by using symbolic links as described in the symbolic link example.

Provider interactive mode

When available, Summon uses the provider's stream mode to retrieve secrets. Whereas the legacy mode required a new process to be created for each secret retrieval, the stream mode can fetch multiple secrets in a single process and allows providers to implement token caching.

If the provider does not support stream mode, Summon uses the legacy mode.

Timeout

By default, Summon will wait up to 60 seconds for a provider to respond when using stream mode. You can change this timeout by setting the CONJUR_HTTP_TIMEOUT environment variable to the desired number of seconds.

Contributing

For more info on contributing, please see CONTRIBUTING.md.

Troubleshooting

For assistance with some issues encountered when first using Summon, please refer to the troubleshooting guide in CONTRIBUTING.md.

Can't find your problem in the troubleshooting guide? File an issue or ask us on Discourse.

License

Copyright (c) 2020 CyberArk Software Ltd. All rights reserved.

Summon is available under the MIT License.