Details
-
Type: Task
-
Status: Closed (View Workflow)
-
Priority: Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:0.25
-
Epic Link:
-
Sprint:Spring 6 : 30 Mar to Apr 10
Description
Currently, the ansible playbooks we are using to deploy App Store instances use a shared variables file "all.yml" to store variables used in multiple roles.
This file contains values for things like secret keys that need to be encrypted. It also contains other variables that do not require encryption.
Combining these two categories of variables into a single file requires us to interleave encrypted and unencrypted values. This makes it awkward to update encrypted values when required. For example, if we delete an AWS access credential and replace it with something new, we will then need to manually encrypt the replacement values using ansible-vault and copy the cypher-text into all.yml. We must do this multiple times for each variable, individually.
To make this process less error-prone, let's create two files:
all.yml - unencrypted variables
secrets.yml - encrypted variables
In this scheme, the entire file "secrets.yml" will be encrypted, not individual values one-by-one as we are doing now.
The file "secrets.yml" will never reside in the git repository itself. It will only be created upon provisioning the control node, which we will do manually. To protect the file, we will add "secrets.yml" as an entry to the .gitignore file for the reposiotry.
To remind us which variables need to be defined, we will create another file called "protected_variables.txt" that simple lists each variable, e.g.,
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
... (and son on)
To provision the control node, the user will create the "secrets.yml" file using "protected_variables.txt" as a guide. Next, the user will encrypt the entire file and transfer it to the control node.
As a reminder, to encrypt an entire file using ansible-vault, all we need to do is run:
- ansible-vault encrypt secrets.yml
To decrypt it (for editing), run:
- ansible-vault decrypt secrets.yml
To run the playbook, the user can provide a file containing a password and indicate it the location of same in an ansible settings file. Alternatively, the user can enter the password manually by running ansible-playbook with --ask-vault-pass flag.
For a quick refresher on how this works, watch:
https://linuxacademy.com/cp/courses/lesson/course/4489/lesson/7/module/366
Attachments
Activity
Resolution | Done [ 10000 ] | |
Status | Post-merge Testing In Progress [ 10003 ] | Closed [ 6 ] |
Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
Status | Reviewing Pull Request [ 10303 ] | Merged Needs Testing [ 10002 ] |
Status | Pull Request Submitted [ 10101 ] | Reviewing Pull Request [ 10303 ] |
Status | Ready for Pull Request [ 10304 ] | Pull Request Submitted [ 10101 ] |
Status | First Level Review in Progress [ 10301 ] | Ready for Pull Request [ 10304 ] |
Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
Status | To-Do [ 10305 ] | In Progress [ 3 ] |
Description |
Currently, the ansible playbooks we are using to deploy App Store instances use a shared variables file "all.yml" to store variables used in multiple roles.
This file contains values for things like secret keys that need to be encrypted. It also contains other variables that do not require encryption. Combining these two categories of variables into a single file requires us to interleave encrypted and unencrypted values. This makes it awkward to update encrypted values when required. For example, if we delete an AWS access credential and replace it with something new, we will then need to manually encrypt the replacement values using ansible-vault and copy the cypher-text into all.yml. We must do this multiple times for each variable, individually. To make this process less error-prone, let's create two files: all.yml - unencrypted variables secrets.yml - encrypted variables In this scheme, the entire file "secrets.yml" will be encrypted, not individual values one-by-one as we are doing now. The file "secrets.yml" will never reside in the git repository itself. It will only be created upon provisioning the control node, which we will do manually. To protect the file, we will add "secrets.yml" as an entry to the .gitignore file for the reposiotry. To remind us which variables need to be defined, we will create another file called "protected_variables.txt" that simple lists each variable, e.g., AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY ... (and son on) To provision the control node, the user will create the "secrets.yml" file using "protected_variables.txt" as a guide. Next, the user will encrypt the entire file and transfer it to the control node. As a reminder, to encrypt an entire file using ansible-vault, all we need to do is run: * ansible-vault encrypt secrets.yml To decrypt it (for editing), run: * ansible-vault decrypt secrets.yml To run the playbook, the user can provide a file containing a password and indicate it the location of same in an ansible settings file. Alternatively, the user can enter the password manually by running ansible-playbook with --ask-vault-pass flag. |
Currently, the ansible playbooks we are using to deploy App Store instances use a shared variables file "all.yml" to store variables used in multiple roles.
This file contains values for things like secret keys that need to be encrypted. It also contains other variables that do not require encryption. Combining these two categories of variables into a single file requires us to interleave encrypted and unencrypted values. This makes it awkward to update encrypted values when required. For example, if we delete an AWS access credential and replace it with something new, we will then need to manually encrypt the replacement values using ansible-vault and copy the cypher-text into all.yml. We must do this multiple times for each variable, individually. To make this process less error-prone, let's create two files: all.yml - unencrypted variables secrets.yml - encrypted variables In this scheme, the entire file "secrets.yml" will be encrypted, not individual values one-by-one as we are doing now. The file "secrets.yml" will never reside in the git repository itself. It will only be created upon provisioning the control node, which we will do manually. To protect the file, we will add "secrets.yml" as an entry to the .gitignore file for the reposiotry. To remind us which variables need to be defined, we will create another file called "protected_variables.txt" that simple lists each variable, e.g., AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY ... (and son on) To provision the control node, the user will create the "secrets.yml" file using "protected_variables.txt" as a guide. Next, the user will encrypt the entire file and transfer it to the control node. As a reminder, to encrypt an entire file using ansible-vault, all we need to do is run: * ansible-vault encrypt secrets.yml To decrypt it (for editing), run: * ansible-vault decrypt secrets.yml To run the playbook, the user can provide a file containing a password and indicate it the location of same in an ansible settings file. Alternatively, the user can enter the password manually by running ansible-playbook with --ask-vault-pass flag. For a quick refresher on how this works, watch: https://linuxacademy.com/cp/courses/lesson/course/4489/lesson/7/module/366 |
Rank | Ranked higher |
Field | Original Value | New Value |
---|---|---|
Epic Link | IGBF-1388 [ 17463 ] |