Linux build without gnome-keyring

[xmj]

Hello,

We're evaluating different terraform-credentials-helper implementations and so far this looks the most promising.

And comparing the test-linux branch against master, I see that you want to use gnome-keyring to obtain credentials.

https://github.com/bendrucker/terraform-credentials-keychain/compare/test-linux

Do you think there's a way to do it without gnome-keyring?

This might help reducing the size of docker-images running on CI/CD, where I'd personally rather do anything but install gnome dependencies

Best regards,
Johannes

[bendrucker]

Glad to hear it! Opened #20 for Linux, I remember working on it but can't remember whether I got stuck.

Re: Linux support in general:

https://github.com/99designs/keyring#keyring

Keyring is primarily designed to support desktop users but the Encrypted File backend seems like it would be suitable for CI.

[xmj]

Thank you for the link, Keyring looks interesting. As I understand it's a spin-off of aws-vault, where one can just use saml2aws for the same purpose with non-technical users.

Do you see a way to hook it in to terraform-credentials-keychain, or would it be more suitable to a separate project terraform-credentials-keyring?

Best regards,
Johannes

[bendrucker]

Keyring is the Go library that provides a generic keyring API, compatible with macOS Keychain among other backends. It was extracted from aws-vault since using the operating system's secure storage facility is broadly useful for any Go program that needs to persist credentials.

This credential helper plugin, per the readme uses keyring. It supports all the backends that keyring supports, in theory. I developed this for my own use and to offer to coworkers all on Macs, and running end-to-end tests on GitHub Actions on a macOS runner also proved straightforward. I'd like to have automated E2E tests for Linux as well, Windows too if possible.

I did think about renaming to terraform-credentials-keyring but chose not to because:

• It would take work to update 😉
• I'm primarily targeting this at desktop users and macOS is pretty popular
• There's no generic name for OS secure storage. Keyring is a perfectly fine library name but also the name of a popular implementation (GNOME Keyring). Seems like a different version of the same naming problem.

[bendrucker]

Most of the backends in keyring should work without any configuration. Perhaps not the file one. I'll have to get E2E tests going to confirm, which might reveal some required config, opportunities to add flags, etc.

I also have to ask, are you planning on using this entirely in CI, on desktop, both? Can you describe the setup more? Implementing secure storage in a container or really any non-desktop environment is inherently tricky. The security choices available to users are described for macOS in the docs:

https://github.com/bendrucker/terraform-credentials-keychain#security

I'd imagine other desktop credential storage tools for other operating systems behave similarly. If you choose to "Always Allow" access, any program can then invoke the credential helper and obtain your credentials. There's still a huge practical security advantage—malware scanning for common credentials (e.g. ~/.aws/credentials) won't compromise you. A successful attack would have to target this plugin specifically.

In a headless environment, there's no user to enter a login password and unlock the storage. Plus you need to get the Terraform Cloud token into storage. Credential helpers are called via terraform login for storing a token. That's an interactive command. In a headless environment you'd have to call the plugin's store command directly.

In the end you get something similar to desktop with "Always Allow"—security by obscurity. You're protected against scanning for well-known files and env vars but completely unprotected by an attacker with knowledge of this plugin.

For a CI environment with containers, I'd be more inclined to just pass the token as an environment variable and focus on automated token rotation. Users can create their own tokens via the Terraform Cloud API. In theory you might be able to create a token for each run (depends on the limit), but you could also rotate on a time interval. Using short-lived tokens protects against common file/env credential harvesters as well as MITM, disgruntled ex-employees copying service account credentials, and other more sophisticated/targeted abuse. A successful attack has to be fast and fully automated.

[xmj]

Hi,

Thanks for the feedback. The workflow we're building is a mix of Jenkins and Terraform Enterprise. Terraform CLI schedules plans on the TFE backend, tests run (terratest etc), and if successful, terraform apply runs on the TFE backend, after which, other tests may run again.

I'd want to store the tokens in a tamper-proof keychain on the Jenkins slaves' file system. Now Jenkins has a credentials store, but it takes me 2min to find a way to decrypt it, given read-access to either file system or the credentials itself. So I'm looking for a way to store workspace-admin tokens in a slightly more secure manner.

I did look at terraform-credentials-env [1], which is something you could use if you were happy with Jenkins' credentials store.
We also have an OSS Hashicorp Vault flying around but then the question is where do I store role/secret IDs.

We currently use TFE Team tokens to do CI/CD with, and as we have "enough" pipelines running at all times, credential harvesters might harvest a credential... just not the right one. Which is why I'm looking into all this in the first place ;-)

Best
Johannes

PS: Thanks for the explanations on keyring... and "derp" ;-)

[1] https://github.com/apparentlymart/terraform-credentials-env

[bendrucker]

Gotcha, sounds good. Worth a look at Docker's credential helpers too:

https://github.com/docker/docker-credential-helpers

Seems like the majority of Linux users are using GNOME Keyring as far as I can tell.

[nogweii]

Note that the keyring library doesn't depend on gnome-keyring explicitly, or KDE's kwallet either. Both of them expose a machine-local API over DBus, which is what the library uses. In fact, that local API is a standard called "Secret Service", so you can replace gnome-keyring or kwallet with another implementation, if you so choose.

Anyways, there is no direct dependency on GNOME's or KDE's libraries and applications.