4 ms·

I discovered the first (surprisingly good) use case for keybase the other day -- Terraform encrypted outputs which you can configure by simply providing your ke

I discovered the first (surprisingly good) use case for keybase the other day -- Terraform encrypted outputs which you can configure by simply providing your keybase id. Extremely convenient. Perfectly joined the dots between a complicated but secure thing (you had to store sensitive state in S3 with server-side-encryption, which made it way too complicated to have sensitive data in a small side project) and the throwaway easy but very insecure thing (store the state locally/in a private git repo). Of course, absolutely ZERO crossover between that kind of utility and this Stellar thing. I'd like them to find more life-improving nuggets of utility like that instead. Find more places in your life where you want something encrypted ad-hoc but don't want to memorise your GPG key ID. Any time someone would normally whisper to tell you something could be a candidate.

ithkuil 7y ago
Could you please describe in more details the workflow with terraform?
- phrotoma 7y ago
  This was my first intro to Keybase as well. I believe it is still limited to the AWS provider (Google provider maintainers are dead set against it last I checked) but for resources like `aws_iam_user` you can specify either a GPG pubkey or a keybase username and upon creating the user the Terraform provider will generate a random password and encrypt it so you can store it / share it safely.
- deadbunny 7y ago
  (Using the IAM module because I'm lazy) module "iam-user_foobar" { source = "terraform-aws-modules/iam/aws//modules/iam-user" version = "2.3.0" name = "foobar" pgp_key = "keybase:foobar" force_destroy = true create_iam_user_login_profile = true create_iam_access_key = false password_length = "${var.password_length}" } This sets the users password then PGP encrypts the password with their keys from keybase. You can then use the module output to get the pgp encrypted password and pass it to the user (manually, email etc...). Otherwise it will put the password in plaintext in the state, not a massive issue as you can set it to require changing next login. But eliminates the even slight chance of leakage.
  - vageli 7y ago
    You can also encrypt the state with KMS (for example) and manage access to the key to prevent casual access to your secrets in statefiles. Uploading encrypted values in state is interesting though and using keybase for that is awesome!
jrockway 7y ago
> Perfectly joined the dots between a complicated but secure thing (you had to store sensitive state in S3 with server-side-encryption, which made it way too complicated to have sensitive data in a small side project) and the throwaway easy but very insecure thing (store the state locally/in a private git repo). I use git-crypt for storing secrets in git repositories. In the future, I'll probably switch to this, though: https://github.com/bitnami-labs/sealed-secrets https://github.com/bitnami-labs/sealed-secrets

ithkuil 7y ago

Could you please describe in more details the workflow with terraform?

phrotoma 7y ago
This was my first intro to Keybase as well. I believe it is still limited to the AWS provider (Google provider maintainers are dead set against it last I checked) but for resources like `aws_iam_user` you can specify either a GPG pubkey or a keybase username and upon creating the user the Terraform provider will generate a random password and encrypt it so you can store it / share it safely.
deadbunny 7y ago
(Using the IAM module because I'm lazy) module "iam-user_foobar" { source = "terraform-aws-modules/iam/aws//modules/iam-user" version = "2.3.0" name = "foobar" pgp_key = "keybase:foobar" force_destroy = true create_iam_user_login_profile = true create_iam_access_key = false password_length = "${var.password_length}" } This sets the users password then PGP encrypts the password with their keys from keybase. You can then use the module output to get the pgp encrypted password and pass it to the user (manually, email etc...). Otherwise it will put the password in plaintext in the state, not a massive issue as you can set it to require changing next login. But eliminates the even slight chance of leakage.
- vageli 7y ago
  You can also encrypt the state with KMS (for example) and manage access to the key to prevent casual access to your secrets in statefiles. Uploading encrypted values in state is interesting though and using keybase for that is awesome!

jrockway 7y ago

> Perfectly joined the dots between a complicated but secure thing (you had to store sensitive state in S3 with server-side-encryption, which made it way too complicated to have sensitive data in a small side project) and the throwaway easy but very insecure thing (store the state locally/in a private git repo). I use git-crypt for storing secrets in git repositories. In the future, I'll probably switch to this, though: https://github.com/bitnami-labs/sealed-secrets https://github.com/bitnami-labs/sealed-secrets