Photo © www.bluecoat.com

Security Part 2

So there is still a TON of work to do on this setup to make it highly available and resistant.

and the scripts’s have been quite useful to help answer questions in the support channels.. but someone did point out to me the UGLY way the oracle was being handled.

so I decided to use google’s secret manager.

for my purposes it seemed quite useful.

so .. let’s go over what’s needed. (these are naturally embedded into the scripts now, but for more details see https://github.com/petes-fan-club/terra-scripts/blob/main/remote-scripts/create_vms.sh and https://github.com/petes-fan-club/terra-scripts/tree/main/feeder areas

1. create a service account that runs on the machine(s) you need to access the secret. in our case the ‘feeder’ machines
2. setup the privileges that it needs. This one had a trick to it, as you also have to give the service account the logging & monitoring roles as well. This is due to GCP creating machines with a default set of rules, that allow the monitoring & logging agents to do their thing. *BUT* when you specify one scope, it removes all the defaults.
3. create the vm (or stop it, do the changes and start it again) so that it uses your new feeder account, as well as the ‘cloud-platform’ scope (that allows it to access the gcloud APIs).

now the VM is capable of using the secret manager.

we also needed to modify the actual feeder scripts to use it. so we created/updated the secret on our local machine using the password in settings.private, and then used.

note: for even more security, you can restrict which secrets are accessible by which service account as well.

gcloud secrets versions access latest — secret ORACLE_PASSWORD

To access it where we needed to.. so one less ‘at rest’ problem.

I’m kinda happy with how the feeder oracle is. the only open ports on the box are SSH and a google agent.

The only thing really left to do is to modify the code so that it could either

a. handle a ‘password update’ command so that it can re-build the encrypted data it stores in the voter.json file

b. modify my scripts so that we store the ‘voter.json’ file as a secret as well

c. modify the code so that it uses the gcloud API directly so that it stores the private key it the secret manager.

Now if I was doing this where there was a LOT of risk (say they key held millions of dollars worth of stuff behind it) I would choose the vTPM option and let the actual hardware do the signing, so key would never appear in ‘userspace’ at all… but that would be more costly as it would incur charges for every signature (instead of every restart as this configuration does)

A Note about charges

While I am no starving artist, I am hoping that the validator charges will cover the costs. Currently the costs of running a very bare-bones validator is about $20/day. This is mainly due to requiring the ‘balanced’ / SSD option for disk. There will also come a time when Terra reaches it’s limit on validators, and the small guys will be pushed out.

So, if you think this was useful, feel free to delegate to the pete’s fan club validator.

and again this validator it dedicated to the people who introduced us to Terra. In my case it was Pete.