vault_client_auth_approle: Vault AppRole Authentication Configuration

In vimc/vaultr: Vault Client for Secrets and Sensitive Data

Vault AppRole Authentication Configuration

Description

Vault AppRole Authentication Configuration

Vault AppRole Authentication Configuration

Details

Interact with vault's AppRole authentication backend. For more details about this, see the vault documentation at https://developer.hashicorp.com/vault/docs/auth/approle

Super class

vaultr::vault_client_object -> vault_client_auth_approle

Methods

Public methods

• vault_client_auth_approle$new()

• vault_client_auth_approle$custom_mount()

• vault_client_auth_approle$role_list()

• vault_client_auth_approle$role_write()

• vault_client_auth_approle$role_read()

• vault_client_auth_approle$role_delete()

• vault_client_auth_approle$role_id_read()

• vault_client_auth_approle$role_id_write()

• vault_client_auth_approle$secret_id_generate()

• vault_client_auth_approle$secret_id_list()

• vault_client_auth_approle$secret_id_read()

• vault_client_auth_approle$secret_id_delete()

• vault_client_auth_approle$login()

Inherited methods

• vaultr::vault_client_object$format()
• vaultr::vault_client_object$help()

---

Method new()

Create a vault_client_approle object. Not typically called by users.

Usage

vault_client_auth_approle$new(api_client, mount)

Arguments

api_client

A vault_api_client object

mount

Mount point for the backend

---

Method custom_mount()

Set up a vault_client_auth_approle object at a custom mount. For example, suppose you mounted the approle authentication backend at ⁠/approle-dev⁠ you might use ar <- vault$auth$approle2$custom_mount("/approle-dev") - this pattern is repeated for other secret and authentication backends.

Usage

vault_client_auth_approle$custom_mount(mount)

Arguments

mount

String, indicating the path that the engine is mounted at.

---

Method role_list()

This endpoint returns a list the existing AppRoles in the method.

Usage

vault_client_auth_approle$role_list()

---

Method role_write()

Creates a new AppRole or updates an existing AppRole. This endpoint supports both create and update capabilities. There can be one or more constraints enabled on the role. It is required to have at least one of them enabled while creating or updating a role.

Usage

vault_client_auth_approle$role_write(
  role_name,
  bind_secret_id = NULL,
  secret_id_bound_cidrs = NULL,
  token_bound_cidrs = NULL,
  policies = NULL,
  secret_id_num_uses = NULL,
  secret_id_ttl = NULL,
  token_num_uses = NULL,
  token_ttl = NULL,
  token_max_ttl = NULL,
  period = NULL,
  enable_local_secret_ids = NULL,
  token_type = NULL
)

Arguments

role_name

Name of the AppRole

bind_secret_id

Require secret_id to be presented when logging in using this AppRole (boolean, default is TRUE).

secret_id_bound_cidrs

Character vector of CIDR blocks; if set, specifies blocks of IP addresses which can perform the login operation.

token_bound_cidrs

Character vector of if set, specifies blocks of IP addresses which can use the auth tokens generated by this role.

policies

Character vector of policies set on tokens issued via this AppRole.

secret_id_num_uses

Number of times any particular SecretID can be used to fetch a token from this AppRole, after which the SecretID will expire. A value of zero will allow unlimited uses.

secret_id_ttl

Duration, after which any SecretID expires.

token_num_uses

Number of times issued tokens can be used. A value of 0 means unlimited uses

token_ttl

Duration to set as the TTL for issued tokens and at renewal time.

token_max_ttl

Duration, after which the issued token can no longer be renewed.

period

A duration; when set, the token generated using this AppRole is a periodic token; so long as it is renewed it never expires, but the TTL set on the token at each renewal is fixed to the value specified here. If this value is modified, the token will pick up the new value at its next renewal.

enable_local_secret_ids

Boolean, if TRUE, then the secret IDs generated using this role will be cluster local. This can only be set during role creation and once set, it can't be reset later.

token_type

The type of token that should be generated via this role. Can be service, batch, or default to use the mount's default (which unless changed will be service tokens).

---

Method role_read()

Reads the properties of an existing AppRole.

Usage

vault_client_auth_approle$role_read(role_name)

Arguments

role_name

Name of the AppRole

---

Method role_delete()

Deletes an existing AppRole from the method.

Usage

vault_client_auth_approle$role_delete(role_name)

Arguments

role_name

Name of the AppRole to delete

---

Method role_id_read()

Reads the RoleID of an existing AppRole.

Usage

vault_client_auth_approle$role_id_read(role_name)

Arguments

role_name

Name of the AppRole

---

Method role_id_write()

Updates the RoleID of an existing AppRole to a custom value.

Usage

vault_client_auth_approle$role_id_write(role_name, role_id)

Arguments

role_name

Name of the AppRole (string)

role_id

Value to be set as RoleID (string)

---

Method secret_id_generate()

Generates and issues a new SecretID on an existing AppRole. Similar to tokens, the response will also contain a secret_id_accessor value which can be used to read the properties of the SecretID without divulging the SecretID itself, and also to delete the SecretID from the AppRole.

Usage

vault_client_auth_approle$secret_id_generate(
  role_name,
  metadata = NULL,
  cidr_list = NULL,
  token_bound_cidrs = NULL
)

Arguments

role_name

Name of the AppRole.

metadata

Metadata to be tied to the SecretID. This should be a named list of key-value pairs. This metadata will be set on tokens issued with this SecretID, and is logged in audit logs in plaintext.

cidr_list

Character vector CIDR blocks enforcing secret IDs to be used from specific set of IP addresses. If bound_cidr_list is set on the role, then the list of CIDR blocks listed here should be a subset of the CIDR blocks listed on the role.

token_bound_cidrs

Character vector of CIDR blocks; if set, specifies blocks of IP addresses which can use the auth tokens generated by this SecretID. Overrides any role-set value but must be a subset.

---

Method secret_id_list()

Lists the accessors of all the SecretIDs issued against the AppRole. This includes the accessors for "custom" SecretIDs as well.

Usage

vault_client_auth_approle$secret_id_list(role_name)

Arguments

role_name

Name of the AppRole

---

Method secret_id_read()

Reads out the properties of a SecretID.

Usage

vault_client_auth_approle$secret_id_read(
  role_name,
  secret_id,
  accessor = FALSE
)

Arguments

role_name

Name of the AppRole

secret_id

Secret ID attached to the role

accessor

Logical, if TRUE, treat secret_id as an accessor rather than a secret id.

---

Method secret_id_delete()

Delete an AppRole secret ID

Usage

vault_client_auth_approle$secret_id_delete(
  role_name,
  secret_id,
  accessor = FALSE
)

Arguments

role_name

Name of the AppRole

secret_id

Secret ID attached to the role

accessor

Logical, if TRUE, treat secret_id as an accessor rather than a secret id.

---

Method login()

Log into the vault using AppRole authentication. Normally you would not call this directly but instead use ⁠$login⁠ with method = "approle" and proving the role_id and secret_id arguments. This function returns a vault token but does not set it as the client token.

Usage

vault_client_auth_approle$login(role_id, secret_id)

Arguments

role_id

RoleID of the AppRole

secret_id

SecretID belonging to AppRole

Examples

vaultr::vault_client(addr = "https://localhost:8200")$auth$approle

vimc/vaultr documentation built on Nov. 11, 2023, 8:21 a.m.