Skip to content

Latest commit

 

History

History
281 lines (189 loc) · 7.21 KB

07-16_secrets.md

File metadata and controls

281 lines (189 loc) · 7.21 KB
Raw

Secrets

Key Value
Author(s) Neal.Coleman, Jordan.Brockopp
Reviewers David.May, Emmanuel.Meinen, Kelly.Merrick
Date July 17th, 2019
Status Complete

Background

Please provide a summary of the new feature, redesign or refactor:

This feature will enable the ability to provide multiple secret engines (backends) for customers.

Vault is a tool for securely storing and accessing secrets.

Adding another secret backend, like Vault, would provide a greater sophistication to our secret configuration options.

In order to accomplish adding more secret backends, we also must involve refactoring the existing secrets implementation.

Please briefly answer the following questions:

  1. Why is this required?
  • provide compatible functionality with existing CI solutions
  • provide extra layers of redundancy to secrets management
  • enables adding other secret backends (like Kubernetes)
  • greater sophistication to secret configurations
  1. If this is a redesign or refactor, what issues exist in the current implementation?

The current API/CLI setup all assume we're interacting with a single secret backend.

An example of the current structure:

// POST   /api/v1/repositories/:owner/:repository/secrets

Unless we were to use query parameters, there isn't a way for us to address which backend we should be creating the new secret in.

  1. Are there any other workarounds, and if so, what are the drawbacks?

N/A

  1. Are there any related issues? Please provide them below if any exist.

N/A

Design

Please describe your solution to the proposal. This includes, but is not limited to:

  • new/updated endpoints or url paths
  • new/updated configuration variables (environment, flags, files, etc.)
  • performance and user experience tradeoffs
  • security concerns or assumptions
  • examples or (pseudo) code snippets

The below represents the modifications necessary regarding the 3 secret types:

  • repo
  • org
  • shared

API

The below endpoints would be created for the new secrets functionality.

The idea is using the :engine and :type parameters in the path, will enable support for future secret engines while not having to actually add new endpoints for them.

// POST   /api/v1/secrets/:engine/:type/:owner/:name/
// GET    /api/v1/secrets/:engine/:type/:owner/:name/
// GET    /api/v1/secrets/:engine/:type/:owner/:name/
// PUT    /api/v1/secrets/:engine/:type/:owner/:name/
// DELETE /api/v1/secrets/:engine/:type/:owner/:name/

NOTE: The below endpoints will be deprecated and supported only in 0.4.x versions.

// POST   /api/v1/repositories/:owner/:repository/secrets
// GET    /api/v1/repositories/:owner/:repository/secrets
// GET    /api/v1/repositories/:owner/:repository/secrets/:secret
// PUT    /api/v1/repositories/:owner/:repository/secrets/:secret
// DELETE /api/v1/repositories/:owner/:repository/secrets/:secret

CLI

Repo

# Example Vault path for repo secret storage
secret/repo/{org}/{repo}/foo

# Example Vela CLI command for repository secret storage
vela create secret --engine vault --type repo --org github --repo octocat --name foo --value bar

# Example Vault CLI return for repository secret storage
vault read secret/repo/github/octocat/foo
Key                 Value
---                 -----
refresh_interval    10h
repo                github/octocat
value               bar

Org

# Example Vault path for org secret storage
secret/org/{org}/foo

# Example Vela CLI command for repository secret storage
vela create secret --engine vault --type org --org github --repo * --name foo --value bar

# Example Vault CLI return for org secret storage
vault read secret/org/github/foo
Key                 Value
---                 -----
refresh_interval    10h
repo                github/*
value               bar

Shared

# Example Vault path for shared secret storage
secret/shared/{org}/{team}/foo

# Example Vela CLI command for shared secret storage
vela create secret --engine vault --type shared --org github --team octokitties --name foo --value bar

# Example Vault CLI return for shared secret storage
vault read secret/shared/github/octokitties/foo
Key                 Value
---                 -----
refresh_interval    10h
team                github/octokitties
value               bar

Pipeline

Current secrets YAML definition:

secrets:
  # native secrets implicit
  - name: docker_username

  # native secrets explicit
  - name: docker_password
    type: native
    key:  docker_username

  # external secrets
  - name: docker_token
    type: vault
    key:  secrets/org/docker/token

Proposed secrets YAML definition:

secrets:
  # native secrets implicit
  - name: docker_username

  # native secrets explicit
  - name: docker_password
    key:  /{org}/{repo}/docker_password
    engine: native
    type: repo

  # vault secrets explicit
  - name: docker_token
    key:  /{org}/docker/token
    engine: vault
    type: org

  # vault secrets explicit
  - name: docker_url
    key:  /{org}/{team}/docker/url
    engine: vault
    type: shared

Implementation

Please briefly answer the following questions:

  1. Is this something you plan to implement yourself?

Yes

  1. What's the estimated time to completion?

2 weeks

Please provide all tasks (gists, issues, pull requests, etc.) completed to implement the design:

Questions

Please list any questions you may have:

N/A