sidecred

Sidecred handles the lifecycle of your credentials "on the side". It supports multiple credential providers and secret stores, and handles the lifecycle from creation, to rotations and eventual deletion.

Why?

Security and convenience. E.g. our CI/CD requires AWS credentials in order to deploy terraform templates, and instead of using static credentials tied to one or more IAM users, we can use Sidecred to create and rotate a temporary set of credentials that are tied to an IAM role and written to a secret store where it can be accessed by our CI/CD. Likewise we can use Sidecred to provision and rotate temporary access tokens tied to a Github App instead of using machine users to create personal access tokens (PAC) that are not automatically rotated.

Installation

You can install sidecred by downloading it from the releases, or you can easily deploy to AWS using the following terraform template: https://github.com/telia-oss/terraform-aws-sidecred.

Usage

See sidecred --help for supported flags. Flags can also be set via the environment after prefixing the flag name with SIDECRED_. E.g. --sts-provider-enabled can be set with SIDECRED_STS_PROVIDER_ENABLED=true.

Configuration

---
version: 1

namespace: cloudops

stores:
  - type: secretsmanager
  - type: github
    config:
      repository: telia-oss/sidecred
      secret_template: "{{ .Namespace }}_{{ .Name }}"

requests:
  - store: github 
    creds:
      - type: aws:sts
        name: open-source-dev-read-only
        config:
          role_arn: arn:aws:iam::role/role-name
          duration: 15m
  - store: secretsmanager
    creds:
      - type: github:access-token
        list: 
          - name: itsdalmo-access-token
            config: { owner: itsdalmo }
          - name: telia-oss-access-token
            config: { owner: telia-oss }

As shown above, Sidecred expects a YAML configuration that contains the following elements:

namespace: A namespace (e.g. the name of a team, project or similar) to use when processing the credential requests. Replaces {{ .Namespace }} in secret templates and resource names.
stores: One or more secret stores to use for writing the requested credentials. You can name: stores for readability, or to de-dupe store types.
requests: A list of credential requests that map creds: to a store:. Each credential request under creds: should specify a credential type: and unique name: for the credentials, and optionally a config: which is passed to the credential provider.

See below for a list of supported secret stores and credential providers.

Supported secret stores

Secret stores are used to store credentials generated by providers. The following credential stores are supported:

Inprocess (inprocess)
AWS Secrets Manager (secretsmanager)
AWS SSM Parameter store (ssm)
Github Repository Secrets (github)

Supported providers

Providers are used to generate/provide credentials (see the provider documentation for details):

Github (github)
AWS (aws)
Random (random)
Artifactory (artifactory)

Supported backends

Sidecred keeps an internal state to track credential expiration and to perform cleanup for external resources when they are no longer needed. Backends are used to store this internal state, and Sidecred currently supports the following backends:

File
AWS S3

Development

Local

# Enable the STS provider
export AWS_REGION=eu-west-1
export SIDECRED_STS_PROVIDER_ENABLED=true
export SIDECRED_STS_PROVIDER_SESSION_DURATION=20m

# Enable the Github provider
export SIDECRED_GITHUB_PROVIDER_ENABLED=true
export SIDECRED_GITHUB_PROVIDER_KEY_ROTATION_INTERVAL=20m
export SIDECRED_GITHUB_PROVIDER_INTEGRATION_ID="<value>"
export SIDECRED_GITHUB_PROVIDER_PRIVATE_KEY="<value>"

# Chose a secret store and configure it
export SIDECRED_SSM_STORE_ENABLED=true
export SIDECRED_SSM_STORE_PATH_TEMPLATE="/sidecred/{{ .Namespace }}/{{ .Name }}"

# Chose a state backend and configure it
export SIDECRED_STATE_BACKEND=file

# Enable debug logging
export SIDECRED_DEBUG=true

After setting the above you can execute sidecred as follows:

# The Github App credentials (integration ID and private key) and AWS STS credentials
# should be populated using e.g. vaulted or aws-vault:
go run ./cmd/sidecred --config ./cmd/sidecred/testdata/config.yml

jentz / sidecred