Docs

# Cycloid Credentials

Cycloid Credentials manager centrally stores, accesses, and distributes secrets like API keys, AWS IAM/STS credentials, X.509 certificates, SSH credentials, and more.

# What's a Cycloid credential?

Credentials path is composed of a type and name. path can be seen as the credential full name to use. Each path contain one or several fields. And each fields are composed of a key and a value.

Path and field name are closely linked together. To give an example, I want to provide a database password to my application. To satisfy that, I could define a Cycloid credential of type custom, named db_password containing the field named password and secret as value.

The generated path would be custom_db_password.

TIP

The path is automatically generated based on your secret name and type, but if you desire to set a different one, please click on the grey lock next to it.

To use it into a Cycloid pipeline, you will refer to it using the format <cred path>.<cred field name>. So, you would write ((custom_db_password.password)) in your pipeline.

Another example for an application which requires a login and password, you could create as well custom_app_creds containing fields login and password to reflect to:

custom_app_creds.login = foo
custom_app_creds.password = bar
1
2

Read Vault in the pipeline section to have more details about how to use Cycloid credentials into a pipeline.

We recommend you to also read Organize data in vault section to see the different ways to store credentials before starting to create your own.

WARNING

By default a Vault credential exists, to be able to access your credentials. This is both used by our API and potentially by your pipelines to securely fetch your secrets without exposing them. Please do not remove it.

Default view

# Types of credentials

You can create the following credentials:

  1. AWS
  2. GCP
  3. Azure (storage)
  4. SSH
  5. Basic Authentication
  6. Swift
  7. Custom

# AWS

These are used in various situations: fetching logs for the application, from cloudwatch, reading the billing status of your application, managing resources via terraform, etc.

The format is pretty simple, at it is composed of the access key and the secret key (opens new window).

AWS

# GCP

A valid Google Cloud Platform service account key (opens new window) in JSON format.

AWS

# Azure (storage)

Storage account name and access key to use an Azure Blob Storage.

AWS

# SSH

The SSH credentials are in fact SSH private keys, as they are mostly used to access git repositories storing either: pipeline/ansible/terraform configuration or your own application code.

The key has to be a valid SSH private key otherwise you will receive an error.

SSH

# Basic Authentication

The Basic Authentication is commonly used on web services. It requires a simple username and password that can be passed as headers or in the url.

Basic Authentication

# Swift

Swift credential will be used to configure Swift external backend. It's based on V3 authentication against Openstack's Keystone.

swift

# Custom

Custom credential type are basically any number of key/values that you want. That allows to store most type of credentials in the way that you would like: whether http authentication, database password, ansible-vault password, etc.

Custom

# Organize your custom credential data

Cycloid credentials manager is based on vault, this allows you to create key/value credentials or also key with several fields and values.

Credentials manager lets you specify or override the path of the vault key for advanced user who want to limit the scope of variables based on https://concourse-ci.org/creds.html

Before adding stuff in credentials manager, you should ask yourself some questions:

  • Do I need a unique credential? ex: a Slack hook url could be the same for all projects.
  • Where would my credentials be used? In the pipeline, Terraform or Ansible.
  • Is my credential linked to a specific project?
  • Will this project have several env? (staging/prod)
  • Will my credentials be different for each env?

Those could result in 4 ways to store your credentials:

  1. Regular key value
# Format
name: value

# Example
slack_hook_url: https://...
1
2
3
4
5
  1. Env named key value
# Format
env_name: value

# Example
prod_htaccess: foo
staging_htaccess: bar
1
2
3
4
5
6
  1. Key containing value for each envs
# Format
name:
  Env: value
  Env2: value

# Example
htaccess:
  prod: foo
  staging: bar
1
2
3
4
5
6
7
8
9
  1. Global secret containing several key values for each env
# Format
path_name:
  Env_name: value
  Env_name2: value
  Env2_name: value
  Env2_name2: value

# Example
lambda_secrets:
  prod_htaccess: foo
  prod_key: 123
  staging_htaccess: bar
  staging_key: 456
1
2
3
4
5
6
7
8
9
10
11
12
13

This use case could help when using the vault provider in Terraform. For each credential path, you have to define it in Terraform to use it. It might be easier for example to declare all secret env vars for a lambda in the same path instead of splitting them into several paths.

← Cost Estimation →