vaultr (version 1.0.2)

vault_api_client: Vault Low-Level Client

Description

Low-level API client. This can be used to directly communicate with the vault server. This object will primarily be useful for debugging, testing or developing new vault methods, but is nonetheless described here.

Methods

is_authenticated

Test if the vault client currently holds a vault token. This method does not verify the token - only test that is present. Usage:

is_authenticated()

set_token

Set a token within the client Usage:

set_token(token, verify = FALSE, quiet = FALSE)

Arguments:

• token: String, with the new vault client token

• verify: Logical, indicating if we should test that the token is valid. If TRUE, then we use $verify_token() to test the token before setting it and if it is not valid an error will be thrown and the token not set.

• quiet: Logical, if TRUE, then informational messages will be suppressed.

verify_token

Test that a token is valid with the vault. This will call vault's /sys/capabilities-self endpoint with the token provided and check the /sys path. Usage:

verify_token(token, quiet = TRUE)

Arguments:

• token: String, with the vault client token to test

• quiet: Logical, if TRUE, then informational messages will be suppressed.

server_version

Retrieve the vault server version. This is by default cached within the client for a session. Will return an R numeric_version object. Usage:

server_version(refresh = FALSE)

Arguments:

• refresh: Logical, indicating if the server version information should be refreshed even if known.

GET

Send a GET request to the vault server Usage:

GET(path, ...)

Arguments:

• path: The server path to use. This is the "interesting" part of the path only, with the server base url and api version information added.

• ...: Additional httr-compatible options. These will be named parameters or httr "request" objects.

LIST

Send a LIST request to the vault server Usage:

LIST(path, ...)

Arguments:

• path: The server path to use. This is the "interesting" part of the path only, with the server base url and api version information added.

• ...: Additional httr-compatible options. These will be named parameters or httr "request" objects.

POST

Send a POST request to the vault server Usage:

POST(path, ...)

Arguments:

• path: The server path to use. This is the "interesting" part of the path only, with the server base url and api version information added.

• ...: Additional httr-compatible options. These will be named parameters or httr "request" objects.

PUT

Send a PUT request to the vault server Usage:

PUT(path, ...)

Arguments:

• path: The server path to use. This is the "interesting" part of the path only, with the server base url and api version information added.

• ...: Additional httr-compatible options. These will be named parameters or httr "request" objects.

DELETE

Send a DELETE request to the vault server Usage:

DELETE(path, ...)

Arguments:

• path: The server path to use. This is the "interesting" part of the path only, with the server base url and api version information added.

• ...: Additional httr-compatible options. These will be named parameters or httr "request" objects.

Examples

# NOT RUN {
server <- vaultr::vault_test_server(if_disabled = message)
if (!is.null(server)) {
  # Ordinarily, we would use the "vault_client" object for
  # high-level access to the vault server
  client <- server$client()
  client$status()

  # The api() method returns the "api client" object:
  api <- client$api()
  api

  # This allows running arbitrary HTTP requests against the server:
  api$GET("/sys/seal-status")

  # this is how vaultr is internally implemented so anything can
  # be done here, for example following vault's API documentation
  # https://www.vaultproject.io/api/secret/kv/kv-v1.html#sample-request-2
  api$POST("/secret/mysecret", body = list(key = "value"))
  api$GET("/secret/mysecret")
  api$DELETE("/secret/mysecret")

  # cleanup
  server$kill()
}
# }