cyberark/summon-aws-secrets

Summon provider for AWS Secrets Manager

summon-aws-secrets

Summon provider for AWS Secrets Manager

Install

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

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

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

If you are running an Alpine-based system, you will need to add libc6 compatiblity package (apk add libc6-compat)!

Variable IDs

Variable IDs are used as identifiers for fetching Secrets. These are made up of a secret name (required) and secret key path (optional).

The format used is my/secret/name#mysecretkeypath, where #mysecretkeypath is optional and only relevant when the value returned by my/secret/name alone is valid JSON.

secret name (required)

This is the AWS secret name, which must be ASCII letters, digits, or any of the following characters: /_+=.@-

secret key path (optional)

The secret key path provides access to top-level values inside secrets stored as valid JSON.

Example

Example Secret JSON in aws:

{
  "user-1": "password-1",
  "user-2": "password-2",
  "user-3": "password-3"
}

Use of summon-aws-secrets without secret key path:

$ summon-aws-secrets prod/aws/iam/user/robot/access_key_id
{ "user-1": "password-1", "user-2": "password-2", "user-3": "password-3"}

Use of summon-aws-secrets with secret key path:

$ summon-aws-secrets prod/aws/iam/user/robot/access_key_id#user-2
password-2

Usage in isolation

Give summon-aws-secrets a variable ID and it will fetch it for you and print the value to stdout.

$ # Configure in similar fashion to AWS CLI see https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html
$ summon-aws-secrets prod/aws/iam/user/robot/access_key_id
8h9psadf89sdahfp98

Flags

summon-aws-secrets supports a single flag.

• -v, --version Output version number and quit

Usage as a provider for Summon

Summon is a command-line tool that reads a file in secrets.yml format and injects secrets as environment variables into any process. Once the process exits, the secrets are gone.

Example

As an example let's use the env command:

Following installation, 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

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.

Wrap the env in summon:

$ # Configure in similar fashion to AWS CLI see https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html
$ summon --provider summon-aws-secrets env
...
AWS_ACCESS_KEY_ID=AKIAJS34242K1123J3K43
AWS_SECRET_ACCESS_KEY=A23MSKSKSJASHDIWM
...

summon resolves the entries in secrets.yml with the AWS Secrets Manager provider and makes the secret values available to the environment of the command env.

Configuration

This provider uses the same configuration pattern as the AWS CLI to connect to AWS.

Contributing

We welcome contributions of all kinds to this repository. For instructions on how to get started and descriptions of our development workflows, please see our contributing guide.

summon-aws-secrets's Issues

Add code coverage to summon-aws-secrets

Add code coverage to this project.

Acceptance Criteria:

• Code coverage should be measured across all tests defined in this repository every time a build is run in any branch.
• Coverage report should include:
  • Line Coverage (including highlighting which lines are covered and which are not - not just giving a percentage)
  • Conditional Coverage
  • Optionally, other kinds of coverage such as Package, Class, File, or Method coverage
• Coverage report should be created in or converted to Cobertura format as part of build to allow for ingestion into coverage aggregation tools
• Coverage report should be archived in the Jenkins build using the cobertura command as shown at https://github.com/cyberark/conjur-api-ruby/blob/072d21e01e46382ee4d577e180c1269f8ff9f36e/Jenkinsfile#L27
• Coverage report should be uploaded to Code Climate with each build

fix: multiple # in a secret identifier are not resolved correctly

This issue follows from @jepperson2's comment at #6 (comment)

As a result, keys that include '#' or '$' fail to be fetched properly. For example, a secrets.yml like this one fails:

MY_SECRET1: !var fakeSecret#$temp
MY_SECRET2: !var fakeSecret##temp
MY_SECRET3: !var fakeSecret#temp#
MY_SECRET4: !var fakeSecret#te#mp

...
In the above example, MY_SECRET2 is populated with the entire JSON struct of the secret while MY_SECRET3 and MYSECRET4 are blank.

These are edge cases, but I'm noting them here in case users of this release run into issues with keys with these characters. One resolution to the problems with '#' could be to use strings.Index instead of strings.Split. I believe the resolution to handling the '$' character would have to be made in the Summon repo.

New release v0.4.0

When do you think that you will release the version 4.0.0 with the last commits?

Fix build failures due to goconvey updates

Summary

Current builds are failing to run due to issues with goconvey and the underlying assertions library.

Upstream: smartystreets/goconvey#600

AC:

• Builds are working again

Go version is updated to 1.15

AC:

• Go version is updated to 1.15

Ability to specify versions of secrets to retrieve

Is your feature request related to a problem? Please describe.

I would like the ability to specify a specific version of a secret to retrieve from a Summon file. For example, Summon currently allows the ability to retrieve a specific key out of a multi-key value secret through the use of the <secret_path_here>#<key> syntax.

• This would be useful in the case of doing credential rotations where new secret values added in via the update_secret operation will automatically assign the version AWSCURRENT to the new values, and the version ID AWSPREVIOUS to the old values.

It would be sweet if a user could also specify the version (i.e. !var <path_to_secret>#<key>#<version>)

See: AWS SecretsManager Staging Labels

Describe the solution you would like

A clear and concise description of what the desired end result(s) would be.

• Specifying a version with ^<version_label> in the path (i.e. <path_to_secret>^<version_id> will retrieve the secret with that specific VersionID.

Describe alternatives you have considered

• Nil

Additional context

Nil

Is there a way to pass a role name or otherwise specify an AWS_REGION in the example provided?

Our typical AWS setup involves using a particular profile name that uses a role name, e.g. ~/.aws/config has

[profile myprofile]
role_arn = arn:aws:iam::<account number>:role/<rolename>
source_profile = default
region=us-east-1

Typically, this means that we either attach a --profile myprofile to all our aws-cli commands or more likely

export AWS_PROFILE=myprofile

ahead of doing any aws-cli commands.

However, summon with summon-aws-secrets doesn't seem to recognize AWS_PROFILE.

summon --provider summon-aws-secrets env

after setting AWS_PROFILE, I get

Error fetching variable AWS_ACCESS_KEY_ID: exit status 1: MissingRegion: could not find region configuration

Note that if I use

aws-cli ec2 describe-instances

that works fine, so my aws cli setup is valid.

Is there a way that I can pass the region , profile and role correctly to this in the case where I maintain multiple profiles?

ERROR: summon-aws-secrets only works on 64-bit systems for MAC

Summary

Provide brief overview and context for the discovered bug.

Steps to Reproduce

1. Installing summon-aws-secrets in Mac M1 machine
2. See error

Expected Results

Installation should complete normally

Actual Results

Installing summon-aws-secrets provider
ERROR: summon-aws-secrets only works on 64-bit systems
Exiting installer
make: *** [install-summon] Error 1

Reproducible

• Always
• Sometimes
• Non-Reproducible

How to pull secrets that are part of a json structure?

So I've moved along with this and now I've run into a second problem.

I've entered a secret with key and value into AWS Secrets Manager
e.g.

Entered key "my/secret/name" as "my/secret/key" and "my/secret/value" as shown

So, I've entered the following into my secrets.yml:

MY_SECRET: !var my/secret/key/name

If I use

summon -p summon-aws-secrets env

What I get returned is:

MY_SECRET={"mysecretkey":"mysecretvalue"}

which is unfortunately, not very useful if I want to pass it to, for instance, my docker-compose up command which actually expects MY_SECRET=mysecretvalue.

Is there some notation that let's me pull the value associated with "mysecretkey" inside of the AWS secret named my/secret/name?

Tests exist for `main.go`

Is your feature request related to a problem? Please describe.

Currently, there is no test coverage for main.go.

Describe the solution you would like

There exists a file called main_test.go, where we test the various functions inside. This will require a small change to our project structure allowing for declared types and a mocking framework.

Describe alternatives you have considered

No alternative would increase test coverage

Using curl for lastest version

The install script uses either curl or wget to downloads the tarball, but only curl to check the latest version, which breakes the install script on systems that only have wget.

Convert to use Goreleaser for building/publishing

Current build process is pretty manual so we should try to include Goreleaser here as well

AC:

• Goreleaser is used for building packages

standardised CHANGELOG exists, and is validated via pipeline

If the repo has a changelog that doesn't meet the standard, do try to change earlier entries to match the standard.
If the repo doesn't have a changelog use this as a starter:

# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).

## [Unreleased]

Acceptance criteria

• CHANGELOG.md exists and follows the KeepAChangeLog format. For reference consult https://github.com/cyberark/conjur/blob/master/CHANGELOG.md.
• Add parse-changelog validation step to Jenkinsfile. For reference consult https://github.com/cyberark/conjur/blob/master/Jenkinsfile#L27.

Repo has bug and feature request issue templates

AC:
The following templates have been added to the repo, with appropriate component labels:

• Bug template
• Feature request template

Option to base64 encode secrets values

It would be nice to add an option to make a secret's value base64 encoded. This situation is handy when we have a multi-line plain-text secret value.

Pre-releases are automatically generated

Is your feature request related to a problem? Please describe.

With the addition of goreleaser to our building and packaging process, we should
begin using github actions to create a pre-release, similar to other repositories.

Describe the solution you would like

First, we use Goreleaser in a separate script, publish.sh, that will generate a production
version of the summon-aws-secrets binary.

We use github actions to generate a pre-release, and attach the artifacts from the build process.
See the cloudfoundry conjur-tile repo for an example of this.

Describe alternatives you have considered

Gorelease supports generating a release directly through github, without the need for github actions,
but this may require secrets we cannot retrieve through Jenkins.