<p>Another option is to use saltstack's product: salt</p>

<p>This Configuration Management System (CMS) can protect sensitive data in three ways.</p>

<p>1) Pillars; these are securely stored and encrypted key:value or key:list dictionaries stored on your primary computer(s) that you manage the entire cluster from.</p>

<p>This will allow you to create salt scripts that can have that data inserted at time of running into the scripts (so not stored in the actual scripts).</p>

<p>2) GPG cipher; this allows you to write in actual passwords and keys into scripts and have them encrypted into hashes as placeholders for when you store these scripts into a revision control system (github/gitlab/bitbucket).</p>

<p>The GPG key used for encrypting/decrypting is stored on your primary computer (master) for managing the cluster.</p>

<p>3) Salt-cloud; all of your salt scripts are stored in the <code>/srv/salt/</code> directory on the primary machine, however the credentials/keys for spinning up VMs in the cloud is stored in <code>/etc/salt/</code> directory.</p>

<p>This allows you to store the work you share with other people on a project in github, but all the sensitive data salt needs to spin up more resources isnt even in the same directory to be recorded.</p>

<hr>

<p>This will probably super simplify your devops related code as well if you end up using this product.</p>

<p>Resources:
- <a href="https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.gpg.html" rel="nofollow noreferrer">GPG Render</a>
- <a href="https://docs.saltstack.com/en/latest/topics/cloud/" rel="nofollow noreferrer">salt-cloud</a>
- <a href="https://docs.saltstack.com/en/latest/topics/pillar/#pillar-encryption" rel="nofollow noreferrer">pillars</a></p>

CC BY-SA 4.0
2019-02-11T06:25:06.580Z
2019-02-11T11:10:43.403Z
2019-02-11T11:10:43.403Z
Alan-Cugler
<p>Option 1:
You could place your private repo in the same VPC as the instance and then pull code from there. Just make sure the repo cannot be accessed from outside the VPC.</p>

<p>Option 2:
Ssh into the new instance and SCP the binary over.</p>

<p>Option 3:
Use docker and deploy a private container registry (e.g. Amazon ECR). Build the image on your machine / build server and then push it to the registry from where it is available to your instances to pull and execute.</p>

CC BY-SA 4.0
2019-02-10T23:01:35.267Z
2019-02-10T23:01:35.267Z
M. Oberauer
<p>If the repo is on AWS Codecommit, you should be able to access it via a role setup for each type of instance.</p>

<p>See under IAM role here <a href="https://docs.aws.amazon.com/codecommit/latest/userguide/auth-and-access-control.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/codecommit/latest/userguide/auth-and-access-control.html</a></p>

CC BY-SA 4.0
2019-02-12T04:36:14.010Z
2019-02-12T04:36:14.010Z
jdog
<p>I want to setup an auto-scaling configuration but cannot think how I can securely get code from a private repo when I spin up new instances.</p>

<p>I obviously don't want to put passwords in startup scripts, or store private keys somewhere that can be downloaded without a password.</p>

<p>How can I achieve this?</p>

CC BY-SA 4.0
2019-02-12T05:41:21.450Z
Maybe you can try ansible-vault for this?
Krzysztof Wesołowski
<automation><autoscaling><repository><http>
Auto-scaling, how to securely get code from private repo
Adam Copley
# Auto-scaling, how to securely get code from private repo

(Asked by: username_0 on 2019-02-10)

I want to setup an auto-scaling configuration but cannot think how I can securely get code from a private repo when I spin up new instances.

I obviously don't want to put passwords in startup scripts, or store private keys somewhere that can be downloaded without a password.

How can I achieve this?

**Tags:** automation, autoscaling, repository, http

> **Comments:**
> **username_1**: Maybe you can try ansible-vault for this?  

---

## 3 answers

### Answer by username_2 on 2019-02-11. Score: 1

Another option is to use saltstack's product: salt

This Configuration Management System (CMS) can protect sensitive data in three ways.

1) Pillars; these are securely stored and encrypted key:value or key:list dictionaries stored on your primary computer(s) that you manage the entire cluster from.

This will allow you to create salt scripts that can have that data inserted at time of running into the scripts (so not stored in the actual scripts).

2) GPG cipher; this allows you to write in actual passwords and keys into scripts and have them encrypted into hashes as placeholders for when you store these scripts into a revision control system (github/gitlab/bitbucket).

The GPG key used for encrypting/decrypting is stored on your primary computer (master) for managing the cluster.

3) Salt-cloud; all of your salt scripts are stored in the `/srv/salt/` directory on the primary machine, however the credentials/keys for spinning up VMs in the cloud is stored in `/etc/salt/` directory.

This allows you to store the work you share with other people on a project in github, but all the sensitive data salt needs to spin up more resources isnt even in the same directory to be recorded.

---

This will probably super simplify your devops related code as well if you end up using this product.

Resources:
- [GPG Render](https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.gpg.html)
- [salt-cloud](https://docs.saltstack.com/en/latest/topics/cloud/)
- [pillars](https://docs.saltstack.com/en/latest/topics/pillar/#pillar-encryption)


---

### Answer by username_3 on 2019-02-10. Score: 1

Option 1:
You could place your private repo in the same VPC as the instance and then pull code from there. Just make sure the repo cannot be accessed from outside the VPC.

Option 2:
Ssh into the new instance and SCP the binary over.

Option 3:
Use docker and deploy a private container registry (e.g. Amazon ECR). Build the image on your machine / build server and then push it to the registry from where it is available to your instances to pull and execute.


---

### Answer by username_4 on 2019-02-12. Score: 1

If the repo is on AWS Codecommit, you should be able to access it via a role setup for each type of instance.

See under IAM role here <https://docs.aws.amazon.com/codecommit/latest/userguide/auth-and-access-control.html>


---

