Code Monkey home page Code Monkey logo

terraform-provider-bitwarden's Introduction

Terraform Provider for Bitwarden

Tests Coverage Status Go Version Releases

The Terraform Bitwarden provider is a plugin for Terraform that allows to manage different kind of Bitwarden resources. This project is not associated with the Bitwarden project nor 8bit Solutions LLC.

Explore the docs »


Table of Contents

Supported Versions

The plugin has been tested and built with the following components:

The provider likely works with older versions but those haven't been tested.

Usage

The complete documentation for this provider can be found on the Terraform Registry docs.

terraform {
  required_providers {
    bitwarden = {
      source  = "maxlaverse/bitwarden"
      version = ">= 0.6.2"
    }
  }
}

# Configure the Bitwarden Provider
provider "bitwarden" {
  email           = "[email protected]"
}

# Managing Folders
resource "bitwarden_folder" "cloud_credentials" {
  name = "My Cloud Credentials"
}


# Managing Logins and Secure Notes
resource "random_password" "vpn_password" {
  length           = 16
  special          = true
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "bitwarden_item_login" "vpn_credentials" {
  folder_id = bitwarden_folder.cloud_credentials.id

  name      = "VPN Read Only User/Password Access"
  username  = "vpn-user"
  password  = random_password.vpn_password.result
}

resource "bitwarden_item_secure_note" "vpn_note" {
  folder_id = bitwarden_folder.cloud_credentials.id

  name      = "Notes on the preshared Secret"
  notes     = "It's 1234"
}


# Managing Attachments
resource "bitwarden_attachment" "vpn_config" {
  file = "./vpn_config.txt"
  item_id = bitwarden_item_login.vpn_note.id
}


# Using Login information
data "bitwarden_item_login" "mysql_credentials" {
  id = "ec4e447f-9aed-4203-b834-c8f3848828f7"
}

resource "kubernetes_secret" "database" {
  metadata {
    name = "database"
  }

  data = {
    username = data.bitwarden_item_login.mysql_root_credentials.username
    password = data.bitwarden_item_login.mysql_root_credentials.password
  }
}


# Using Attachments
data "bitwarden_attachment" "ssh_credentials" {
  id = "4d6a41364d6a4dea8ddb1a"
  item_id = "59575167-4d36-5a58-466e-d9021926df8a"
}

resource "kubernetes_secret" "ssh" {
  metadata {
    name = "ssh"
  }

  data = {
    "private.key" = data.bitwarden_attachment.ssh_credentials.content
  }
}

See the examples directory for more examples.

Security Considerations

The Terraform Bitwarden provider entirely relies on the Bitwarden CLI to interact with Vaults. When you ask Terraform to plan or apply changes, the provider downloads the encrypted Vault locally as if you would use the Bitwarden CLI directly. Currently, the Terraform SDK doesn't offer a way to remove the encrypted Vault once changes have been applied. The issue hashicorp/terraform-plugin-sdk#63 tracks discussions for adding such a feature.

If you want find out more about this file, you can read Terraform's documentation on Data Storage. Please note that this file is stored at <your-project>/.bitwarden/ by default, in order to not interfer with your local Vaults.

Developing the Provider

If you wish to work on the provider, you'll first need Go installed on your machine (see Requirements above).

To compile the provider, run go install. This will build the provider and put the provider binary in the $GOPATH/bin directory.

To generate or update documentation, run go generate.

In order to run the full suite of Acceptance tests, start a Vaultwarden server:

$ docker run -ti \
  -e I_REALLY_WANT_VOLATILE_STORAGE=true \
  -e ADMIN_TOKEN=test1234 \
  -e LOGIN_RATELIMIT_SECONDS=1 \
  -e LOGIN_RATELIMIT_MAX_BURST=1000000 \
  -e ADMIN_RATELIMIT_SECONDS=1 \
  -e ADMIN_RATELIMIT_MAX_BURST=1000000 \
  -p 8080:80 vaultwarden/server

Then run make testacc.

$ make testacc

License

Distributed under the Mozilla License. See LICENSE for more information.

terraform-provider-bitwarden's People

Contributors

dependabot[bot] avatar marshallasch avatar maxlaverse avatar romaindavaze avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

terraform-provider-bitwarden's Issues

Flag passwords as sensitive

The passwords that are loaded from bitwarden using the plugin are not marked as sensitive in the output of the various terraform commands.

Terraform Version

  • Terraform: 1.1.4
  • bitwarden provider: 0.1.0

Affected Resource(s)

I noticed the issue with data "bitwarden_item_login", but I suspect it is present in all resources.

Terraform Configuration Files

data "bitwarden_item_login" "mysql-credentials" {
  id = var.db_credentials_id
  sensitive = true
}

resource "aws_db_instance" "application_db" {
  username                        = data.bitwarden_item_login.mysql-credentials.username
  password                        = data.bitwarden_item_login.mysql-credentials.password
  ....
}

Expected Behavior

I would expect that the username and password fields, or at least just the password field to be marked as sensitive in the output of the plan command.

Actual Behavior

Output from terraform plan

  # aws_db_instance.application_db will be updated in-place
  ~ resource "aws_db_instance" "application_db" {
      # Warning: this attribute value will no longer be marked as sensitive
      # after applying this change. The value is unchanged.
      ~ password                              = (sensitive value)
      # Warning: this attribute value will no longer be marked as sensitive
      # after applying this change. The value is unchanged.
      ~ username                              = (sensitive)
        # (43 unchanged attributes hidden)
...

The result is both of these variables are no longer marked as sensitive in the output.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform plan

Important Factoids

There is nothing special about this terraform configuration, it is being migrated away from plain variables marked as sensitive to load passwords from bitwarden.

References

The documentation seems to mention that the output fields could be marked as sensitive through the use of the sensitive flag or the sensitive function https://www.terraform.io/plugin/sdkv2/best-practices/sensitive-state

A specific example in the documentation

I'd like to suggest adding an example on how to access custom fields stored in Bitwarden logins. It seems to be possible, however the syntax is unclear, at least to me.

Unable to unlock Vault when using Session Key

I'm unable to fetch login items from a Bitwarden vault using the session key for auth. The error I get is:

╷
│ Error: unable to unlock Vault with provided session key (status: unauthenticated)
│
│   with provider["registry.terraform.io/maxlaverse/bitwarden"],
│   on main.tf line 9, in provider "bitwarden":
│    9: provider "bitwarden" {
│
╵

Terraform Version

1.7.3

Affected Resource(s)

  • data.bitwarden_item_login

Terraform Configuration Files

terraform {
  required_providers {
    bitwarden = {
      source  = "maxlaverse/bitwarden"
      version = ">= 0.7.0"
    }
  }
}

provider "bitwarden" {
  session_key = "<redacted>"
}

data "bitwarden_item_login" "test" {
  id = "<redacted>"
}

output "bitwarden-test" {
  value = data.bitwarden_item_login.test.password
}

Debug Output

https://gist.github.com/landalex/5f01579349ce7a90afdad1c1f197388e

Panic Output

N/A

Expected Behavior

The login item password should have been output

Actual Behavior

The login item could not be loaded because the Bitwarden vault failed to unlock using the session key.

Steps to Reproduce

  1. terraform apply

Important Factoids

I tried setting the session key multiple ways (BW_SESSION, Terraform variable, and directly when initializing the provider as in this example) and they all fail with the same error.

I can successfully fetch this login item using the Bitwarden CLI with bw get item <id> in a terminal session via the BW_SESSION enviornment variable.

References

N/A

Using session key when applying from plan produces unauthenticated error

Hi,

first of all thanks for this very useful provider ! :)

Terraform Version

Terraform v1.1.7 / v1.5.3

Affected Resource(s)

Please list the resources as a list, for example:

  • bitwarden_item_login

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

provider "elasticstack" {
  elasticsearch {}
}

provider "bitwarden" {
  session_key = var.bw_session
  vault_path  = var.bw_vault
  email       = "[email protected]"
  server      = "https://vault.xxx.yyy.zzz"
}

terraform {
  required_version = ">= 1.1.2"
  required_providers {
    bitwarden = {
      source  = "maxlaverse/bitwarden"
      version = ">=0.6.1"
    }
    elasticstack = {
      version = ">=0.6.2"
      source  = "elastic/elasticstack"
    }
  }
}

Expected Behavior

Apply should work directly.

Actual Behavior

Terraform has been successfully initialized!
╷
│ Error: unable to unlock Vault with provided session key (status: unauthenticated)
│ 
│   with provider["registry.terraform.io/maxlaverse/bitwarden"],
│   on provider.tf line 5, in provider "bitwarden":
│    5: provider "bitwarden" {
│ 
╵

Steps to Reproduce

First of all, I'm using a private vaultwarden instance instead of official bitwarden.

vault_path content has been manually copied from a login with bw cli.
session_key has been manually copied from a login with bw cli.

Both values are passed from the CI configuration.

First job:
terraform plan -intput=false -out="plan.cache
plan.cache file is passed as an artifact from first job to second one.

Second job;
terraform apply -intput=false "plan.cache"

If a new terraform plan is launched, then the apply is ok.

Does vault local content and terraform plan could be linked in any way ?

apikey: exit status 1, Cannot read properties of null (reading 'profile')

Hi,

Some version Info about the tools

  • your bitwarden provider is on v0.5.0
  • Terraform v1.4.0 on windows_386
  • bw.exe cli is 1.22.1

versions.tf file

terraform {
  required_version = ">=1.2.3"
  required_providers {
    # https://registry.terraform.io/providers/maxlaverse/bitwarden
    bitwarden = {
      version = "0.5.0"
      source  = "maxlaverse/bitwarden"
    }
  }
}

provider "bitwarden" {
  master_password = var.BITWARDEN_PASSWORD
  client_id       = var.BITWARDEN_CLIENT_ID
  client_secret   = var.BITWARDEN_CIENT_SECRET
  email           = var.LBRPSOFTWARE_GMAIL
  server          = var.BITWARDEN_SERVER
}

variables.tf file

variable "BITWARDEN_PASSWORD" {
  type        = string
  sensitive   = true
}

variable "BITWARDEN_CLIENT_ID" {
  type        = string
  sensitive   = true
}

variable "BITWARDEN_CIENT_SECRET" {
  type        = string
  sensitive   = true
}

variable "LBRPSOFTWARE_GMAIL" {
  type        = string
  sensitive   = true
}

variable "BITWARDEN_SERVER" {
  type        = string
  default     = "https://vault.bitwarden.com"
  sensitive   = true
}

Error

  • Got an error when running this bash script
#!/bin/bash

source $TF_VAR_PATH_LBRP_TF/.bitwarden/.bash_bitwarden

terraform init -upgrade
terraform apply
  • Real values (password, usernames, ...) are loaded via /.bash_bitwarden
  • The Error: Error: error running 'C:\<OK_PATH>....\bw.exe login --apikey': exit status 1, Cannot read properties of null (reading 'profile')

Can you help please, and thanks for your provider! 💖

[Feature request] Ability to support URI on item login resource

Terraform Version

Latest

Affected Resource(s)

bitwarden_item_login

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

NA

Debug Output

NA

Panic Output

NA

Expected Behavior

Allow the ability to populate the URI on item login resource on bitwarden vault

Actual Behavior

Does not support this ?

Steps to Reproduce

NA

Important Factoids

NA

References

NA

Receiving 'Rate limit exceeded' error on high number of api calls

Terraform Version

$ terraform -v
Terraform v1.3.7
on linux_amd64

Affected Resource(s)

  • bitwarden_item_login

Terraform Configuration Files

resource "bitwarden_item_login" "app" {
  name            = "${local.bw_item_prefix}-app"
  username        = local.APP_USER
  password        = local.APP_PASSWORD
  organization_id = local.bw_organization_id
  notes           = local.bw_notes
  favorite        = false
  collection_ids  = [local.bw_collection_app]

  uri {
    value = local.domain
  }

  dynamic "field" {
    for_each = local.bw_fields
    content {
      name = field.key
      text = field.value
    }
  }

  field {
    name = "service"
    text = "app"
  }
}

Debug Output

Unfortunately I cannot provide this due to the sensitive nature of the project.

Panic Output

Unfortunately I cannot provide this due to the sensitive nature of the project.

Expected Behavior

  • Successful creation of many Bitwarden login items.

Actual Behavior

  • Many of these errors:
    image
  • Applying a second time creates the remaining items.

Steps to Reproduce

  1. terraform apply
  2. yes
  3. Many item creation failures with 'Rate limit exceeded. Try again later.' error.` (I tried finding this error in the source code of Bitwarden repos and this provider repo but it shows up nowhere.)

Important Factoids

This is probably not an issue with this provider, but I'm creating this anyway because I cannot find any information anywhere if a rate limit is implemented (on this provider, bitwarden cli or bitwarden api). Bitwarden may not understand why lots of API calls are happening, unfortunately this is pretty much how Terraform works. So I'm hoping to gather more information through this ticket so I can create a more full ticket on the bitwarden community forum, and so I can reference this ticket. (EDIT: I created a ticket there too: https://community.bitwarden.com/t/rate-limit-exceeded-error-on-high-number-of-bitwarden-cli-calls/50203)

References

I found some community posts which seem related:

[ISSUE] GPG Key expired

Hi there,

it seems that the gpg key isn't valid anymore when using the plugin on terraform versions > 1.6.0.

[Feature Request] Add organization collection `data` type and `resource` type

Hello again!

I really like the provider and we use it a lot at my current project.
However, currently we have to hardcode a lot of the collection ID's in our Terraform code, we'd like to be able to either pull the collection ID via a data type or manage the collection via Terraform using the resource type.
I've not found a roadmap or anything but I assume you're planning on adding this functionality in the long run.
Is this something you're working on already? If not, I might have a go at it myself in my spare time, but I'm not very familiar with Go.

Thanks in advance.

[Incident] Cannot access self hosed bitwarden instance because of self-signed certificate

Hi there,
we have a self hosted on prem bitwarden installation. Access is limited to internal users so we use a self signed certificate from our internal CA.

Access to bitwarden with Bitwarden CLI is running fine. We had to set NODE_EXTRA_CA_CERTS to our CA Certificate correctly.

Using the Terraform plugin isnt working, I am getting the following error:

Error: 'exit status 1' while running 'login --apikey': , request to https://internal.server.com/identity/connect/token failed, reason: self-signed certificate in certificate chain

with provider["registry.terraform.io/maxlaverse/bitwarden"],
on main.tf line 18, in provider "bitwarden":
18: provider "bitwarden" {

Is there a way to trust our internal CA?

Configuration:

terraform {
required_providers {
  bitwarden = {
    source  = "maxlaverse/bitwarden"
    version = ">= 0.6.3"
    }
  }
}
provider "bitwarden" {
  server="https://internal.server.com"
  email="xxxxx"
  master_password = "yyyyy"
  client_id = "zzzzzz"
  client_secret = "ssssss"
}

Text fields created by provider are not visible by GUI clients

Terraform Version

1.5.4

Affected Resource(s)

Please list the resources as a list, for example:

  • bitwarden_item_login

Terraform Configuration Files

resource "bitwarden_item_login" "this" {
  name        = "server"
  username = var.ssh_user
  password = var.ssh_pass

  field {
    name    = "test"
    text    = "passed"
  }
}

Expected Behavior

A "login" item is created in Bitwarden with an additional "test" text field visible in Bitwarden HTTP or GUI client.

Actual Behavior

A text field is visible using bw CLI tool only. The queried parameter looks like this(some attributes ommitted for brevity):

{
  "object": "item",
  "id": "80098baa-0966-4758-89af-0831ae33c58c",
  "organizationId": null,
  "folderId": null,
  "type": 1,
  "reprompt": 0,
  "name": "server",
  "notes": null,
  "favorite": false,
  "fields": [
    {
      "name": "test",
      "value": "passed"
    }
  ],
  "login": {
    "username": "root",
    "password": "secret",
    "totp": null,
    "passwordRevisionDate": null
  },
  "collectionIds": [
  ],
  "revisionDate": "2023-08-01T22:59:05.915Z",
  "creationDate": "2023-08-01T22:41:35.031Z",
  "deletedDate": null
}

here we can see an expected attribute is defined as:

    {                             
      "name": "test",
      "value": "passed"
    } 

however, when the same parameter is created manually it looks like this:

    {                             
      "name": "test",                                               
      "value": "passed",                                            
      "type": 0,                  
      "linkedId": null            
    } 

we can see currently there are "type" and "linkedId" attributes missing. The "type" attribute is the most important here, without it the value is not visible in the Bitwarden GUI or web GUI.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply

Important Factoids

Reproduced on a self-hosted Vaultwarden server

Expired GPG key for provider breaks usage with Terraform 1.6.0+

Terraform Version

1.6.0+

Affected Resource(s)

All provider usage.

Terraform Configuration Files

n/a

Debug Output

$ ~/terraform init

Initializing the backend...

Initializing provider plugins...
- Finding maxlaverse/bitwarden versions matching ">= 0.1.1"...
- Installing maxlaverse/bitwarden v0.7.0...
╷
│ Error: Failed to install provider
│
│ Error while installing maxlaverse/bitwarden v0.7.0: error checking signature: openpgp: key expired
╵

Panic Output

Expected Behavior

Provider should be usable.

Actual Behavior

Provider is not usable.

Steps to Reproduce

Use Terraform 1.6.0+ and try to use the Bitwarden provider.

Important Factoids

pub   rsa2048 2017-09-04 [SC] [expired: 2023-09-07]
      77728AF1DA38AD17B660D09EECDE241E60988D8C
uid                      Maxime Lagresle <[email protected]>
uid                      Max Laverse <[email protected]>
uid                      Maxime Lagresle <[email protected]>
uid                      Maxime Lagresle <[email protected]>
uid                      Maxime Lagresle <[email protected]>
sub   rsa2048 2017-09-04 [E] [expired: 2023-09-07]
sub   rsa3072 2020-12-02 [S] [expired: 2022-12-02]
sub   rsa3072 2020-12-02 [A] [expired: 2023-09-07]
sub   rsa3072 2021-07-13 [S] [expired: 2023-07-13]
sub   rsa3072 2022-01-16 [S] [expired: 2023-09-07]

References

Terraform plan/refresh produces "Not found" errors

Issue created out of #61, reported by @leynebe

Terraform Version

$ terraform -v
Terraform v1.3.7
on linux_amd64

Affected Resource(s)

  • bitwarden_item_login

Terraform Configuration Files

resource "bitwarden_item_login" "app" {
  name            = "${local.bw_item_prefix}-app"
  username        = local.APP_USER
  password        = local.APP_PASSWORD
  organization_id = local.bw_organization_id
  notes           = local.bw_notes
  favorite        = false
  collection_ids  = [local.bw_collection_app]

  uri {
    value = local.domain
  }

  dynamic "field" {
    for_each = local.bw_fields
    content {
      name = field.key
      text = field.value
    }
  }

  field {
    name = "service"
    text = "app"
  }
}

Debug Output

No debug output yet

Panic Output

No panic output

Expected Behavior

Items should have been refreshed during planning

Actual Behavior

Errors with 404s not found
216559774-aef38898-bed5-411a-919b-aab3762f8d17

Steps to Reproduce

Issue happen to @leynebe

This might warrant its own ticket but I'm also occasionally encountering a failure in tf refresh of login items when applying (after a failed apply)

It happened to me as well after removing the local Vault

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

  • GH-1234

[Feature request] Support Bitwarden SSO/BW_SESSION environment variable

Hi there,

Terraform Version

n/a

Affected Resource(s)

General login/usage of bw CLI

Terraform Configuration Files

n/a

Debug Output

n/a

Panic Output

n/a

Expected Behavior

Support logging in to Bitwarden CLI with "bw login --sso" and then utilisation of the BW_SESSION environment variable inside the provider, rather than expecting to perform the whole login inside the provider - which won't work with SSO login.

Actual Behavior

As far as I can tell from documentation and the source code, this method of using Bitwarden does not seem to be supported.

Steps to Reproduce

n/a

Important Factoids

n/a

References

n/a

[bug] Possible bug when using apikey login

Hello,
I'm not sure if this is a true bug or if I've misconfigured something. When attempting to run a plan action in terraform 1.5.2 with the 0.6.1 bitwarden provider I get an error stating the below. However I am not using organization keys and if I run bw.exe --apikey separately the login attempt is successful. I'm running this on windows 11 . As for reproducing it, the startupcommands is the cmd script I'm using to run this. Any insights on what I may have missed would be appreciated, happy to provide any other info that may be useful.

│ Error: 'exit status 1' while running 'login --apikey': , Invalid API Key; Organization API Key currently not supported

│ with module.Docker.provider["registry.terraform.io/maxlaverse/bitwarden"],
│ on Docker_Clusters\Providers.tf line 10, in provider "bitwarden":
│ 10: provider "bitwarden" {

Gist with relevant files: https://gist.github.com/43a01d61b1f7a1b3262edbc8bf291952.git

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.