When using Terraform, I find that storing state remotely has great benefits. If you work with others or on multiple machines, remote state allows re-using Terraform defined infrastructure without copying the state manually to all other users. More importantly, it allows a “core” set of resources to be defined and owned by one project while the root level output resources are re-usable in other related Terraform projects.

To store state remotely, add a backend to store the state such as:

terraform {
  backend "s3" {
    bucket = "<your bucket name>"
    key = "default"
    region = "us-east-1"
  }
}

Then you need to run terraform init after adding the backend to your Terraform config.

To import remote state (say you have a core infrastructure Terraform project), add another resource to import:

data "terraform_remote_state" "core_infrastructure" {
  backend = "s3"
  workspace = "${terraform.workspace}"
  config {
    bucket = "<bucket with state to import>"
    key = "default"
    region = "us-east-1"
  }
}

The core infrastructure that I generally have are definitions for DNS zones (so related projects can import the DNS managed zone identifier and create subdomains), wildcard SSL certificates for test domains, and general repository definitions for where the code is stored.

If you have multiple users, you will need to look into remote state locking solutions as well with your backends,

For my $HOME/.npmrc config, I have the following config:

prefix=~/.npm-global

So when installing npm modules globally, they will be installed in a directory that’s owned by my user instead of to a system directory. This prevents write permission issues when trying to install modules not owned by my user.

I’ve had a couple of YubiKey devices for U2F auth for a while now. They are much easier to use than digging out your two-factor authenticator app.

Recently, I purchased a YubiKey 4. The major feature addition to me is the support for OpenPGP to make it easier to use OpenPGP subkeys to sign data, encrypt data, and authenticate.

The feature list for YubiKey 4 is long, but after some usage, it is like there are many separated and different functions all in one physical package.

How-To Setup and Use

So far the best OpenPGP guide with YubiKey 4 has been Suvash Thapaliya’s thorough step-by-step guide.

The OpenPGP functionality works well. Instead of a long password to remember and enter every time, you can insert the YubiKey, enter in the PIN to unlock, and then remove the key when done.

My main issue now is key management. I’m still experimenting with how to update my subkeys’ expiration times.

Random Notes

Lock-out

For functionality that requires a PIN, you can control how many wrong PINs it takes before blocking the device. You actually have 2 PINs to remember. One is the normal PIN used for daily use. The other is the PUK (Personal Unlocking Key) which unlocks the PIN if the wrong PIN was entered too many times.

If you want to reset your device, you may need to force your PIN and PUK to both be blocked, and then you can perform a device reset.

Different PINs for Different Functions

You may find the official OpenPGP documentation from Yubico helpful, but what I really needed was their Reset OpenPGP applet instructions. I managed to lock my YubiKey because I did not understand that each functionality of the key has unique PINs.

For instance, using their PIV Tool, you need to set a PIN to be able to log in to macOS using the YubiKey. However, it is not the same PIN that the OpenPGP applet uses. So be careful to remember the default PINs (123456 for normal entry and 12345678 for admin) when doing the initial setup for each functionality and to change them.

Their forum also has posts explaining how to reset the OpenPGP applet and other helpful advice.