My application contains some of sentive variables that need to be protected, including data base connection, for example.
There is a secrets in the azure container apps that i can use, but there is a key vault too. What is the best choice to use secret variables in the azure container apps?
Thank you very much
Carlos
Quote from the aws cdk docs:
If you need to use a pre-existing secret, the recommended way is to manually provision the secret in AWS SecretsManager and use the Secret.fromSecretArn or Secret.fromSecretAttributes method to make it available in your CDK Application
Why is that? Is it because it's not ideal to save the plain text secret into code?
Or we don't want the secret to appear in the cloudformation template?
Yes and yes. Earlier CDK versions did not even permit passing text values to the Secret constructor. We only recently got the secretStringBeta1: string prop along with a stern warning:
It is highly encouraged to leave this field undefined and allow SecretsManager to create the secret value. The secret string -- if provided -- will be included in the output of the cdk as part of synthesis, and will appear in the CloudFormation template in the console. This can be secure(-ish) if that value is merely reference to another resource (or one of its attributes), but if the value is a plaintext string, it will be visible to anyone with access to the CloudFormation template (via the AWS Console, SDKs, or CLI).
Our CDK code and generated templates are meant to be deterministic and version-controlled, further heightening the risk of leakage if plaintext secrets are used.
Edit: Per #gshpychka's comment, a safe alternative to importing with Secret.fromSecretArn is to construct a new Secret without a secret value. This creates a secret with a random password, which you change post-deploy in the Console. This approach helpfully ties the secret's lifecycle to the Stack and lets you set its properties in the context of the Stack.
The official boilerplate code injects the npm token as follows
NODE_AUTH_TOKEN: ${{secrets.npm_token}}
How do I access and set this variable? I cant find it in the GUI.
Go to your project in Github
Select the Settings tab
Click the Secrets section in the left hand menu
Add a new secret and provide a name (e.g. npm_token) and a value.
In addition to the GUI, you now (January 2020) have a GitHub Actions API(!, still beta though), as announced here.
And it does include a GitHub Actions Secrets API:
Create or update an repository secret:
Creates or updates an organization secret with an encrypted value. Encrypt your secret using LibSodium.
You must authenticate using an access token with the admin:repo scope to use this endpoint.
GitHub Apps must have the secrets organization permission to use this endpoint.
PUT /repos/{owner}/{repo}/actions/secrets/{secret_name}
Get a repository secret
Gets a single secret without revealing its encrypted value.
Anyone with write access to the repository can use this endpoint.
GitHub Apps must have the secrets permission to use this endpoint.
GET /repos/:owner/:repo/actions/secrets/:name
So the GUI is no longer the sole option: you can script and get/set an Actions secret through this new API.
This page is hard to find, but it exists in the official docs here: Creating and using secrets (encrypted variables).
Copied from the docs below for convenience:
Secret names cannot include any spaces. To ensure that GitHub redacts
your secret in logs, avoid using structured data as the values of
secrets, like JSON or encoded Git blobs.
On GitHub, navigate to the main page of the repository.
Under your repository name, click Settings.
In the left sidebar, click Secrets.
Type a name for your secret in the "Name" input box.
Type the value for your secret.
Click Add secret.
The link above has a bit more info around using secrets as well.
I've created a simple CLI that can help you achieve that - https://github.com/unfor19/githubsecrets
This CLI is based on the official API. You can install it with pip or use Docker, read the README.md for more information
We have installed and configured Hashicorp Vault AppRole authentication for one server, by storing the role_id and secret_id in a local file on the server, and we're able to have code on the server read the values from file, authenticate to Vault, receive a token and then read the secrets it needs from Vault. So far so good. However, the secret_id expires after 31 days, and so the process fails.
I've read up on the concepts of using AppRoles, and they seem like the perfect fit for our use case, but for this expiration. We don't want to have to re-generate the secret_id every month.
From what I've read, if you create the role without setting secret_id_ttl it should be non-expiring, but that isn't the case. This may be due to how the AppRole auth method is configured, but I haven't seen anything solid on this.
So I found an article on the Hashicorp website where AppRoles are discussed in detail. The article gives good arguments for expiring secret_id's in a CI/CD environment, even illustrating how this works in 8 simple steps. I understand how this works, but the article fails to mention how the CI/CD and Orchestrator systems themselves are authenticated to Vault? Or am I missing something?
In the end, I want to have the secret_id not expire. Ever.
Without additional support from your environment you will have to write some logic in your installer, and have a service manager of some sort to start your services. In many cloud environments, you may already have the equivalent entities (Terraform, Cloud Formation, etc.) and you should leverage their secrets management capabilities where needed.
For custom installations, here is a workflow that I have used.
Have an installation manager process that can be invoked to perform installation / upgrade. Make sure installation / upgrade of services is always through this process.
Have a service manager process that is responsible for starting individual services and monitoring them / restarting them. Make sure service start-ups are always via this service manager.
During installation, generate self-signed certificates for Vault, installation manager and service manager. Vault certificates should trust the certs for the installation manager and the service manager. Store these with limited permission (600) in directories owned by the installation user or the service manager user as the case may be. Set up certificate-based authentication in Vault using these certs.
These credentials should have limited capabilities associated with them. The installation manager should only be able to create new roles and not delete anything. The service manager should only be able to create secrets for the named roles created by the installation manager, and delete nothing.
During installation / upgrade, the installation manager should connect to Vault and create all necessary service-specific roles. It should also be able to set role ids for individual services in per-service config files that the services may read on start-up.
During each service's start-up, the service manager should connect to Vault and create secret ids corresponding to each service's role. It should set the secret id in an environment variable and start the service. The secret id should have time-bound validity (by setting TTLs) so that they cannot be used for much beyond the creation of the auth token (see #7).
Each service should read the role id from the config file, and the secret id from the environment variable. It should then generate the auth token using these two, and use the token to authenticate itself with vault for its lifetime.
It is possible to create a Vault AppRole with a secret_id that essentially never expires. However, this should be limited to use on a Vault development server -- one that does not contain any production credentials -- and for use in a development environment.
That being said, here's the procedure I used based on several articles in the Vault documentation, but primarily AppRole Pull Authentication.
This assumes that the Vault approle authentication method is already installed at approle/ and that you are logged in to Vault, have root or admin privileges on the Vault server and have a valid, non-expired token.
Note: For the values supplied for the fields below, the maximum value that vault seems to accept is 999,999,999. For the TTL fields, that is the number of seconds which comes out to more than 31 years. That's not forever, but it is long enough that renewing the secret_id will probably be somebody else's problem (SEP).
# Vault server address to be used by the Vault CLI.
export VAULT_ADDR="https://vault-dev.example.com:8200/"
# Vault namespace to be used by the CLI.
# Required for Cloud and Enterprise editions
# Not applicable for Open Source edition
export VAULT_NAMESPACE="admin"
# The name of the Vault AppRole
export VAULT_ROLE=my-approle
# Override defaults on the approle authentication method
# NOTE: In this command, the field names, default-lease-ttl
# and max-lease-ttl contain dashes ('-'), NOT
# underscores ('_'), and are preceded by a single
# dash ('-').
vault auth tune \
-default-lease-ttl=999999999 \
-max-lease-ttl=999999999 approle/
# Override defaults on the approle
# NOTE: In this command, the field names, secret_id_ttl and
# secret_id_num contain underscores ('_'), NOT
# dashes ('-'), and are NOT preceded by a single
# dash ('-').
vault write auth/approle/role/my-approle \
secret_id_ttl=999999999 \
secret_id_num_uses=999999999
# Create a new secret_id for the approle which uses the new defaults
vault write -f auth/approle/role/my-approle/secret-id
Update the server config file to use the new secret_id and you are ready to go.
As the OP has noted, the Hashicorp Vault documentation assumes that the application is able to authenticate, somehow, to the vault and then retrieve the secret ID (possibly wrapped) from the vault and then, use that to authenticate and fetch a token used to actually work with secrets. The answers here are posing alternative approaches to retrieving that initial token.
Alan Thatcher wrote a blog article, Vault AppRole Authentication, that provides another well thought out approach:
Create a policy that allows the user to retrieve the secret-id and role-id, but nothing else.
Create a long lived, periodic/renewable token based on that policy.
Store the long lived token securely, e.g. as a Kubernetes secret
At runtime, use the long-lived token to:
acquire the secret-id and role-id,
authenticate to vault using these and acquire short-lived token
use current short-lived token to work with secrets
For Java applications, the Spring Vault project supports this approach if you configure the long-lived token as the "initial token" and the approle authencation name, e.g. chef-ro in the blog case.
My personal feeling is that this approach is about as secure but a bit simpler than the mutual TLS approach. I agree that using an infinite TTL for the secret-id is a less secure practice for Production environments.
Thanks to Mr. Thatcher for thinking this one through.
This is probably not the canonnical answer, but I found it empty so decided to add some pointers.
As per Hashicorp Vault AppRole: role-id and secret-id:
Additional brownie information: Ideally, it's best practice to keep
the TTL low, 30 minutes max - if your application is stateful, or
maybe even less if it's a stateless application. The secret key of
Vault approle should also be rotated every 90 days. Please note by
default, Vault approle backend has 31 days of TTL, so if you want to
set it to 90 days, you need to increase TTL of the approle backend as
well.
However (in the same question):
You can generate secret-id with indefinite validity. But doing so will
be as good as keeping your secrets in the configuration file.
For ephemeral instances you can use configuration management to pass in secrets via a third (broker) role. With regard to a server that exists indefinitely, i'm still working that out...
Ideas:
TLS certificates might work well on Windows, don't know about Linux.
GitHub Personal Access Tokens, but this is not org. friendly.
Review the other auth methods available to see if there's one that fits your requirements (e.g. AWS).
I'm looking into vault for securing DB credentials used by various web applications. I've looked over a few Youtube videos, slide shares and even downloaded Vault to experiment with. I can't quite wrap my head around it.How does Vault protect credentials for something like a web application which uses a token to authenticate to Vault with? I'm assuming the Apache process would have to own the vault token (user token, not root token) so it can access secrets for the applications it's running. This would, it seems, expose any secrets the Apache process would have access to in the event of an application compromise. I don't see a big win here so I must be missing a lot.
In a nutshell, Vault supports authentication backends which then allow you to generate tokens. Tokens should be seen as temporary access and are not the same as a key.
In particular, Vault supports authentication with many different systems to generate dynamic secrets and credentials as needed. This is well documented here
In terms of security, the idea is to have a authentication backend as the primary, and the token being generated as a consequence. You are correct in saying hard coding tokens is a security risk. Once generated on the fly, they should have strict permissions and short TTLs. Vault makes this easy as you can define the scope of the token with an ACL.