Terraform Provider for KSM

Keeper Secrets Manager Terraform provider for interacting with vault secrets in Terraform builds

Features

The Keeper Terraform Plugin utilizes Keeper Secrets Manager to provide access to secret credentials saved in the Keeper Vault. The Keeper Terraform plugin allows for injecting secrets directly into Terraform builds securely using Keeper's zero-knowledge infrastructure.

• Retrieve secrets from the Keeper Vault to use in Terraform builds

• Inject credentials directly into Terraform build scripts

• Create new secrets and store them in the vault

• Get Files from the Keeper Vault

For a complete list of Keeper Secrets Manager features see the Overview

Prerequisites

This page documents the Secrets Manager Terraform integration. In order to utilize this integration, you will need:

• Keeper Secrets Manager access (See the Quick Start Guide for more details)

  • Secrets Manager add-on enabled for your Keeper account

  • Membership in a Role with the Secrets Manager enforcement policy enabled

• A Keeper Secrets Manager Application with secrets shared to it

  • See the Quick Start Guide for instructions on creating an Application

• An initialized Keeper Secrets Manager Configuration

  • The Terraform integration accepts JSON and Base 64 format configurations

• Terraform 1.0.0+ (1.10.0+ required for ephemeral resources)

Installation

Registry install

The Keeper Secrets Manager provider page is located here

To install this provider, add the following code to your Terraform configuration and run terraform init:

terraform {
  required_providers {
    secretsmanager = {
      source = "keeper-security/secretsmanager"
      version = ">= 1.3.0"
    }
  }
}

provider "secretsmanager" {
  # Configuration options
}

Find the source code in the GitHub repository

Manual Installation

Download the latest version of the Terraform Provider for your platform from our GitHub release page and copy the archive to the corresponding Terraform plugin folder (creating any missing folders in the path). Initialize source with full provider URL: source = "github.com/keeper-security/secretsmanager"

Use the archive matching your OS and CPU architecture (amd64 or arm64). The Mac OS and Linux commands below detect architecture automatically. Windows command shown is for amd64.

Windows (amd64)

SETLOCAL EnableExtensions
SET "PLUGIN_DIR=%APPDATA%\.terraform.d\plugins\github.com\keeper-security\secretsmanager\1.3.0\windows_amd64"
mkdir "%PLUGIN_DIR%" 2>NUL & ^
curl -fsSL https://github.com/keeper-security/terraform-provider-secretsmanager/releases/download/v1.3.0/terraform-provider-secretsmanager_1.3.0_windows_amd64.zip -o "%TEMP%\ksm-tf-provider.zip" && ^
tar -xf "%TEMP%\ksm-tf-provider.zip" -C "%PLUGIN_DIR%" terraform-provider-secretsmanager_v1.3.0.exe && ^
del "%TEMP%\ksm-tf-provider.zip"

Mac OS

Linux

For help on manually installing Terraform Providers, please refer to the official Terraform documentation.

Usage

Configure the Provider

The Keeper Secrets Manager provider is used to interact with the resources supported by Keeper Secrets Manager. The provider needs to be configured with Keeper credentials before it can be used.

terraform {
  required_providers {
    secretsmanager = {
      source  = "keeper-security/secretsmanager"
      version = ">= 1.3.0"
    }
  }
}

provider "secretsmanager" {
  # Specify config contents as a string or load from file
  # credential = "<CONFIG FILE CONTENTS BASE64>"
  credential = file("/path/to/config.json")
}

For CI/CD environments, you can omit the credential attribute entirely and set the KEEPER_CREDENTIAL environment variable instead:

export KEEPER_CREDENTIAL=$(cat ~/.keeper/credential)

Configuration File Contents

• appKey - (Required) Application key.

• clientId - (Required) Client ID.

• privateKey - (Required) Private key.

• hostname - (Optional) By default the plugin connects to keepersecurity.com

For more information on creating a Secrets Manager configuration, see the Configuration Documentation

Get Secrets Using Data Sources

A data source is provided for each standard Keeper record type, which facilitates easy fetching of secret credentials.

Data sources are accessed using the following format:

data "<data_source_name>" "<record_type_reference>" {
    path = "<record_uid>"
}

For example, using a Login type record:

data "secretsmanager_login" "my_login_record" {
    path = "<RECORD_UID>"
}

To access any additional custom fields or standard fields for user defined record types use secretsmanager_field data source

List of supported record types

Record Type	Data Source Name
Address	"secretsmanager_address"
Bank Account	"secretsmanager_bank_account"
Bank Card	"secretsmanager_bank_card"
Birth Certificate	"secretsmanager_birth_certificate"
Contact	"secretsmanager_contact"
Database Credentials	"secretsmanager_database_credentials"
Drivers License	"secretsmanager_driver_license"
Encrypted Notes	"secretsmanager_encrypted_notes"
Field	"secretsmanager_field"
File	"secretsmanager_file"
Folder	"secretsmanager_folder"
Folders	"secretsmanager_folders"
Health Insurance	"secretsmanager_health_insurance"
Login	"secretsmanager_login"
Membership	"secretsmanager_membership"
Passport	"secretsmanager_passport"
PAM Database	"secretsmanager_pam_database"
PAM Directory	"secretsmanager_pam_directory"
PAM Machine	"secretsmanager_pam_machine"
PAM User	"secretsmanager_pam_user"
PAM Remote Browser	"secretsmanager_pam_remote_browser"
Photo	"secretsmanager_photo"
Record	"secretsmanager_record"
Records (for large volume requests)	"secretsmanager_records"
Server Credentials	"secretsmanager_server_credentials"
Software License	"secretsmanager_software_license"
SSH Keys	"secretsmanager_ssh_keys"
SSN Card	"secretsmanager_ssn_card"

To see the fields available to each data source see Record Types Data Source Reference

For more information on record types see Record Types documentation and Commander usage.

Accessing Record Fields

To access a secret credential saved to a field in a record, access the field as part of the data source.

Access the field of a typed record data source

Use this format to access fields of a typed data resource

${ data.<data_source_name>.<record_type_reference>.<field> }

Example: access the password of a login type data source

${ data.secretsmanager_login.my_login_secret.password }

Use the field data source to query any field in a record with Keeper Notation

Create a data source using the "secretsmanager_field" data source type, and specify a field query in the path property.

data "secretsmanager_field" "my_field" {
  path = "<record UID>/field/login"
}

The field query uses the format: "<UID>/field/<field type>"

If you don't know the record UID, you can look up by title using a wildcard * in place of the UID and the optional title attribute:

data "secretsmanager_field" "db_password" {
  path  = "*/field/password"
  title = "Production Database"
}

Returns an error if more than one accessible record matches the title.

Custom Fields

Custom fields are available on standard and PAM resource types and support 43+ field types. For a complete list of supported record types, see the Custom Fields Reference.

Simple Types (String Value)

For simple types like text, email, URL, use a plain string value:

resource "secretsmanager_login" "my_login" {
  folder_uid = "<FOLDER_UID>"
  title      = "App Login"
  
  login {
    value = "myuser"
  }

  # Custom text field
  custom {
    type  = "text"
    label = "Environment"
    value = "production"
  }

  # Custom email field
  custom {
    type  = "email"
    label = "Admin Email"
    value = "[e-mail]"
  }
}

Complex Types (JSON Value)

For complex types like name, address, paymentCard, use jsonencode():

resource "secretsmanager_login" "my_login" {
  folder_uid = "<FOLDER_UID>"
  title      = "App Login"
  
  # Single-entry complex field
  custom {
    type  = "name"
    label = "Admin Name"
    value = jsonencode({
      first  = "John"
      middle = "Q"
      last   = "Public"
    })
  }

  # Multi-entry complex field
  custom {
    type  = "phone"
    label = "Contact Numbers"
    value = jsonencode([
      {
        number = "555-0100"
        type   = "Mobile"
      },
      {
        number = "555-0101"
        type   = "Home"
      }
    ])
  }
}

Field Configuration

Each custom field supports required and privacy_screen attributes:

custom {
  type           = "text"
  label          = "API Key"
  value          = "secret-key-value"
  required       = true       # Mark as required in Keeper Vault
  privacy_screen = true       # Hide from Keeper Vault UI
}

For detailed field type specifications, see the Custom Fields Reference for your record type.

Reading Custom Fields

Custom fields are also available as read-only attributes on all data sources and ephemeral resources. The custom block is a list. Index into it by position or iterate with for:

data "secretsmanager_login" "my_login" {
  path = "<UID>"
}

output "environment_tag" {
  value = data.secretsmanager_login.my_login.custom[0].value
  sensitive = true
}

output "all_custom_labels" {
  value = [for f in data.secretsmanager_login.my_login.custom : f.label]
}

Each element exposes type, label, and value (a string). For complex types (name, address, paymentCard), value is a JSON-encoded object. Use jsondecode() to work with individual sub-fields.

Creating Records With Resources

Keeper provides Terraform resources for the major Keeper record types shown above. Using these resources, Keeper records can be created using the Keeper Secrets Manager Terraform plugin.

To create a record, use the resource corresponding to the record type that you would like to use.

Each record resource requires at least a folder_uid and title as well as values for each record field.

Example login resource

resource "secretsmanager_login" "login" {
    folder_uid = "4PbDLf8UF4od87wJt-fdyQ"
    title = "My Login Record"
    # Additional fields...
}

Using Ephemeral Resources (Terraform 1.10+)

Ephemeral resources are available for all 25 record types in Terraform 1.10 and later. Unlike data sources and resources, ephemeral data is never written to terraform.tfstate, ensuring sensitive credentials don't persist on disk.

Key Benefits:

• Secrets never stored in local or remote state files

• Temporary access only for the duration of your Terraform run

• Full support for all record types (login, bank_account, ssh_keys, pam_machine, etc.)

• Fully compatible with existing data sources and resources

Syntax: Use ephemeral instead of data:

# Data source: stores secret in tfstate
data "secretsmanager_login" "prod_db" {
  path = "<record_uid>"
}

# Ephemeral: secret never stored
ephemeral "secretsmanager_login" "prod_db" {
  path = "<record_uid>"
}

Example: Ephemeral SSH Key Access

ephemeral "secretsmanager_ssh_keys" "deploy_key" {
  path = "<record_uid>"
}

resource "null_resource" "deploy" {
  provisioner "remote-exec" {
    connection {
      type        = "ssh"
      host        = "example.com"
      private_key = ephemeral.secretsmanager_ssh_keys.deploy_key.key_pair[0].private_key
    }
    inline = ["echo connected"]
  }
}

For a complete list of available record types, see the registry documentation for

ephemeral "secretsmanager_*" resources

Custom Fields on Ephemeral Resources

All record-type ephemeral resources expose a read-only custom block, identical to data sources. Custom field values are never stored in state:

ephemeral "secretsmanager_login" "my_creds" {
  path = "<UID>"
}

output "env_label" {
  value     = ephemeral.secretsmanager_login.my_creds.custom[0].label
  ephemeral = true
}

Folder UID

To create records, Keeper Secrets Manager requires a folder UID so it knows where to create new records.

A folder UID can be found in the Keeper Vault or by using Keeper Commander.

The target folder (or its parent shared folder) must be accessible by the Keeper Secrets Manager Application with Can Edit permissions.

Title

The record title.

Record Fields

The value and settings for each record field can be set in the resource. For information on the available fields per record type, see the resource definitions.

Each field is represented as an object in the resource.

Example login field

resource "secretsmanager_login" "login" {
    folder_uid = "<FOLDER_UID>"
    title = "My Login Record"

    login {
        value = "MyUsername"
        label = "Username"
        required = true
    }
}

Setting Field Values

Use the value field to set the intended value for each field. The format of fields can differ, for example the login field type takes a string, while the name field takes an object with "first", "middle" and "last" fields.

For reference of each field's value format see the resource documentation.

Setting Field Settings

Each field can be configured with various settings:

Field	Accepted Value	Description
label	string	The field label
required	boolean	if True, the field will be considered required by the Keeper Vault
privacy_screen	boolean	if True, the field will be hidden in the Keeper Vault

Password Field

The password field has some special features.

Password Generation

Records created using the Terraform plugin can have a password generated automatically. To have the plugin generate a password, do not provide a value field to the password, and instead use generate = "true"

The password generation can be configured to generate a password of a specified length using the complexity field

password {
    generate = "true"
    complexity {
        length = 16
    }
}

Additionally, password fields have an extra configuration setting: enforce_generation which when true will make the Keeper Vault enforce that the password can only be generated and not set by a user.

To have Terraform regenerate a password, it needs to notice a difference in the generate field. To allow for triggering a difference, the generate field accepts both "true" and "yes" values. Change from one to the other to trigger a regeneration.

SSH Key Generation

The secretsmanager_ssh_keys resource can automatically generate an SSH key pair. To trigger generation, omit the key pair value and set generate = "true" on the key_pair field:

resource "secretsmanager_ssh_keys" "example" {
  folder_uid = "<FOLDER_UID>"
  title      = "My SSH Key"

  key_pair {
    generate = "true"
    key_type = "ssh-ed25519"    # default; also supports ssh-rsa, ecdsa-sha2-nistp256/384/521
    # key_bits = 4096           # only used for ssh-rsa; valid values: 2048, 3072, 4096
  }

  # Optional: generate and store a passphrase to encrypt the private key
  passphrase {
    generate = "true"
    complexity {
      length = 32
    }
  }
}

PAM Machine and PAM User resources also support generating a private PEM key via the private_pem_key field using the same generate / key_type / key_bits pattern.

Like passwords, SSH key generation uses "true" or "yes" as valid values. Changing between the two triggers Terraform to detect a diff and regenerate the key pair on the next apply.

resource "secretsmanager_pam_user" "pam_user_with_generated_key" {
  folder_uid = "<FOLDER_UID>"
  title      = "PAM User With Generated Key"

  login {
    value = "svc-deploy"
  }

  private_key_passphrase {
    generate = "yes"
    complexity {
      length = 32
    }
  }

  private_pem_key {
    generate = "yes"
    key_type = "ssh-rsa"
    key_bits = 4096
  }
}

Examples

Read Credentials

This example provisions Keeper Secrets Manager, reads a login type data source, and accesses each field of the data source.

terraform {
  required_providers {
    secretsmanager = {
      source  = "keeper-security/secretsmanager"
      version = ">= 1.3.0"
    }
    local = {
      source  = "hashicorp/local"
      version = "2.1.0"
    }
  }
}

provider "local" {}
provider "secretsmanager" {
  # Option 1: Use file containing base64-encoded credential
  credential = file("~/.keeper/credential")

  # Option 2: Use environment variable (recommended for CI/CD)
  # Leave credential empty to read from KEEPER_CREDENTIAL env var
}

data "secretsmanager_login" "db_server" {
  path = "<record UID>"
}

resource "local_file" "out" {
  filename        = "${path.module}/out.txt"
  file_permission = "0644"
  content         = <<EOT
UID:    ${data.secretsmanager_login.db_server.path}
Type:   ${data.secretsmanager_login.db_server.type}
Title:  ${data.secretsmanager_login.db_server.title}
Notes:  ${data.secretsmanager_login.db_server.notes}
======
Login:    ${data.secretsmanager_login.db_server.login}
Password: ${data.secretsmanager_login.db_server.password}
URL:      ${data.secretsmanager_login.db_server.url}
TOTP:
-----
%{for t in data.secretsmanager_login.db_server.totp~}
URL:    ${t.url}
Token:  ${t.token}
TTL:    ${t.ttl}
%{endfor~}
FileRefs:
---------
%{for fr in data.secretsmanager_login.db_server.file_ref~}
UID:      ${fr.uid}
Title:    ${fr.title}
Name:     ${fr.name}
Type:     ${fr.type}
Size:     ${fr.size}
Last Modified:  ${fr.last_modified}
Content/Base64: ${fr.content_base64}
%{endfor~}
EOT
}

output "db_secret_login" {
  value = data.secretsmanager_login.db_server.login
}

Create a Keeper Record

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    secretsmanager = {
      source  = "keeper-security/secretsmanager"
      version = ">= 1.3.0"
    }
    local = {
      source  = "hashicorp/local"
      version = "2.1.0"
    }
  }
}

provider "local" {}
provider "secretsmanager" {
  # Option 1: Use file containing base64-encoded credential
  credential = file("~/.keeper/credential")

  # Option 2: Use environment variable (recommended for CI/CD)
  # Leave credential empty to read from KEEPER_CREDENTIAL env var
}

resource "secretsmanager_membership" "membership" {
  folder_uid = "<FOLDER UID>"
  title      = "test_membership_resource"
  notes      = "test_membership_resource"

  account_number {
    label          = "MyAccountNumber"
    required       = true
    privacy_screen = true
    value          = "AccountNumber#1234"
  }

  name {
    label          = "Jane"
    required       = true
    privacy_screen = true
    value {
      first  = "Jane"
      middle = "D"
      last   = "Doe"
    }
  }

  password {
    label              = "MyPass"
    required           = true
    privacy_screen     = true
    enforce_generation = true
    generate           = "true"
    complexity {
      length = 16
    }
    # value = "to_be_generated"  # Commented because generate=true
  }
}

resource "local_file" "out" {
  filename        = "${path.module}/out.txt"
  file_permission = "0644"
  content         = <<EOT
FUID:   ${secretsmanager_membership.membership.folder_uid}
UID:    ${secretsmanager_membership.membership.uid}
Type:   ${secretsmanager_membership.membership.type}
Title:  ${secretsmanager_membership.membership.title}
Notes:  ${secretsmanager_membership.membership.notes}
======

Account Number:
---------------
%{for n in secretsmanager_membership.membership.account_number~}
Type:           ${n.type}
Label:          ${n.label}
Required:       ${n.required}
Privacy Screen: ${n.privacy_screen}
Value:          ${n.value}
%{endfor}

Name:
-----
%{for n in secretsmanager_membership.membership.name~}
Type:           ${n.type}
Label:          ${n.label}
Required:       ${n.required}
Privacy Screen: ${n.privacy_screen}
First Name:     ${n.value.0.first}
Middle Name:    ${n.value.0.middle}
Last Name:      ${n.value.0.last}
%{endfor}

Password:
---------
%{for n in secretsmanager_membership.membership.password~}
Type:               ${n.type}
Label:              ${n.label}
Required:           ${n.required}
Privacy Screen:     ${n.privacy_screen}
Enforce Generation: ${n.enforce_generation}
Generate:           %{if n.generate != null}${n.generate}%{endif}
Complexity:         Length = ${n.complexity.0.length}
Value:              ${n.value}
%{endfor}
EOT
}

output "record_uid" {
  value = secretsmanager_membership.membership.uid
}

output "record_title" {
  value = secretsmanager_membership.membership.title
}

Create PAM Records

These snippets assume the terraform and provider "secretsmanager" blocks are already configured as shown above.

resource "secretsmanager_pam_database" "postgres_prod" {
  folder_uid = "<FOLDER_UID>"
  title      = "Production PostgreSQL"

  pam_hostname {
    value {
      hostname = "postgres.prod.example.com"
      port     = "5432"
    }
  }

  pam_settings = jsonencode([{
    connection = [{
      protocol = "postgresql"
      port     = "5432"
      database = "production"
    }]
  }])

  database_type = "postgresql"

  use_ssl {
    value = true
  }
}

resource "secretsmanager_pam_directory" "corp_ad" {
  folder_uid = "<FOLDER_UID>"
  title      = "Corporate AD"

  pam_hostname {
    value {
      hostname = "ad.corp.example.com"
      port     = "636"
    }
  }

  pam_settings = jsonencode([{
    connection = [{
      protocol = "ldaps"
      port     = "636"
    }]
  }])

  directory_type = "Active Directory"

  distinguished_name {
    value = "DC=corp,DC=example,DC=com"
  }

  use_ssl {
    value = true
  }
}

resource "secretsmanager_pam_remote_browser" "internal_admin" {
  folder_uid = "<FOLDER_UID>"
  title      = "Internal Admin Portal"

  rbi_url {
    value = "https://admin.internal.example.com"
  }

  pam_remote_browser_settings = jsonencode([{
    connection = [{
      protocol = "https"
      port     = "443"
    }]
  }])

  # Optional: custom fields
  custom {
    type  = "text"
    label = "Environment"
    value = "production"
  }
}

Read PAM Data Source Outputs

These snippets assume the terraform and provider "secretsmanager" blocks are already configured as shown above.

data "secretsmanager_pam_machine" "host" {
  path = "<PAM_MACHINE_UID>"
}

output "pam_machine_folder_uid" {
  value = data.secretsmanager_pam_machine.host.folder_uid
}

output "pam_machine_totp_uri" {
  value = try(data.secretsmanager_pam_machine.host.totp[0].value, null)
}

output "pam_machine_private_key_passphrase" {
  value     = try(data.secretsmanager_pam_machine.host.private_key_passphrase[0].value, null)
  sensitive = true
}

For more examples, check out the examples folder in the source code.

TOTP attribute shapes differ by record type:

• Login / Bank Account data sources: totp[0].token (live 6-digit code), totp[0].ttl (seconds remaining), totp[0].url (OTP URI)

• PAM Machine / PAM User data sources: totp[0].value (raw otpauth:// URI — use an external TOTP tool to generate a code)

Optimization

The secretsmanager_records data source allows you to fetch multiple Keeper Secrets Manager records in a single API call, significantly reducing API requests and improving performance when dealing with many secrets.

Fetch by UIDs (most efficient):

data "secretsmanager_records" "infrastructure" {
  uids = ["uid1", "uid2", "uid3"]
}

Fetch by exact titles:

data "secretsmanager_records" "by_name" {
  titles = ["Production DB", "Staging DB", "API Keys"]
}

Fetch by regex pattern:

data "secretsmanager_records" "prod_secrets" {
  title_patterns = ["^prod-.*"]  # Records starting with "prod-"
}

titles and title_patterns both fetch all accessible vault records and filter client-side. Use uids whenever possible for better performance. Patterns use Go regex syntax and are limited to 500 characters to prevent ReDoS.

For detailed documentation including all available output attributes, see the secretsmanager_records reference.

Accessing results by UID:

Records are available as a list via records, or as a UID-indexed map via records_by_uid. Each records_by_uid value is a JSON-encoded string. Use jsondecode() to access individual fields:

# Access by list position
output "first_title" {
  value = data.secretsmanager_records.infrastructure.records[0].title
}

# Access by UID — value is a JSON string; use jsondecode() to extract fields
output "specific_record_title" {
  value = jsondecode(data.secretsmanager_records.infrastructure.records_by_uid["uid1"]).title
}