Deployments to an environment supports approvals. To configure an environment for approvals, the following steps must be completed.
There are three roles in an approval:
These roles may be the same account or different accounts.
This deployment initiation can be done manually, by the Deployer, or automated via an Application Pipeline. When a deployment that requires approval is initiated, the deployment enters into a state of Pending Approval.
An email is sent to the eligible Approver(s) indicating a deployment is awaiting approval, with a link to the deploy.
An Approver can approve or decline the deployment. When approving the pending deployment, there are 3 approval options:
|Approve||Approve the deployment. This will approve the application deployment, but not begin the deploy.||Approved|
|Approve and Deploy||Approve and begin the deployment.||In Progress|
|Decline||Decline the deployment. This will cancel the deployment and provide a message on why declined.||Declined|
If the Approver only Approved the deploy, the deploy will enter the state Approved. This state still requires a user (Approver or Account owner) to complete the deploy by clicking the Deploy option.
The approved deployment can also be Canceled.
Note: The Account Owner can both Deploy and Approve deployments.
This document describes setting up and using Pipelines secure packages to securely deliver secret keys.
Secure packages allows you to easily securely encrypt a release that will only be decrypted on deployment.
To illustrate this solution, consider an example scenario where you need to secure a set of applications secrets that differ depending on what environment they deploy to, dev, stage, or production.
There are three secret files and three environments.
Secure packages requires you provision at least two key management servers and they remain up and available for encryptions and decryptions. You can easily rotate in and out key management servers as long as one is up to exchange key information.
If you lose all key management server you can not deploy an encrypted release.
Note: To enable key management on a server, the server must be running Pipelines Agent 3.59 or greater.
To provision a key management server in Pipelines:
Ensure you do this with at least two servers.
Note: These key management servers can still do builds and consume deployments.
Next you will create an application in Pipelines to store the encrypted credentials for future deployments. This will be one application with the three secrets files.
This application must be marked as secure before pushing the first release.
Note: You should setup your own S3 bucket in Pipelines before doing your first push to ensure your encrypted release is in your S3 bucket. To do so see Using Amazon S3 Bucket in Pipelines.
To create a secure application for this scenario do the following:
jdoe@ServerB~$ mkdir securekeys jdoe@ServerB~$ cd securekeys jdoe@ServerB~/securekeys$ cp /keys/dev/secret.cred ./secret.cred.dev jdoe@ServerB~/securekeys$ cp /keys/stage/secret.cred ./secret.cred.stage jdoe@ServerB~/securekeys$ cp /keys/prod/secret.cred ./secret.cred.prod
jdoe/securekeys: Env: - SECRET_FILE: "set_this_value_in_the_distelli_web UI_env_variables" - DESTINATION_FILE: "/opt/application/secret.cred" PkgInclude: - secret.cred.* PostInstall: - if [ $SECRET_FILE == "set_this_value_in_the_distelli_web UI_env_variables"]; then - echo "You must set the SECRET_FILE environment variable in the Pipelines web UI." - rm secret.cred.* - exit 1 - fi - mv -f $SECRET_FILE $DESTINATION_FILE - rm secret.cred.* - chmod 600 $DESTINATION_FILE
Note: This assumes you have installed the Pipelines CLi on this computer. See Installing the Pipelines CLI.
distelli create jdoe/securekeys
You have created the application. Do not do a push of the release. You must first make the application a secure package in the Pipelines web UI.
To enable encryption of your releases do the following:
That is it. When you build or push the application Pipelines will encrypt the release and put it in your S3 bucket.
On the secure computer, return back to the directory where you stored the three secret files and do a
jdoe@ServerB~/securekeys$ distelli push https://www.distelli.com/jdoe/releases/a-123456789abc
You have now created a secure release of your application. You can view the encrypted release in your S3 bucket, but not the contents. You can also view the release in the Pipelines web UI and determine this is an encrypted package by the lock icon.
Note: If you pushed a release before securing the application you can delete that release from your S3 bucket.
Note: You can deploy this release only if you have a key management server.
At this point you can safely delete your clear-text secret files from the directory you created to push to Pipelines.
Next you will set up three environments for doing deplyments to.
Go to each environment and set the appropriate environment variables:
You can now deploy the secure release of the application to your environments. On deployment they will be decrypted, the correct file will be moved to the correct destination, and any other files are destroyed.
You no longer have to keep the secrets in a clear text file. You have them in an encrypted storage and can deploy them as necessary.
If, in the future, the secrets change, you will have to push the secrets back up to a new encrypted release.
Initially, when you setup key servers, you must provision two or more. Imagine the following scenarios.