- Retrieval of passwords from Device42 by reference to their numeric
id
; this exposes the following attributes:id
(which you already know, since it's used as the selector)username
password
label
- That's basically it, right now
- A Device42 host (configured in the
provider {}
block, or from theD42_HOSTNAME
environment variable; defaults toswaggerdemo.device42.com
) - A username with access (can be configured in the
provider {}
block, or from theD42_USERNAME
environment variable) - A password with access (can be configured in the
provider {}
block, or from theD42_PASSWORD
environment variable) - Terraform (tested with
0.12.29
,0.13.5
, and0.14.4
)
# build the binary in the test directory for 0.12.x
go build -o tf_test/0.12/terraform-provider-device42
# Terraform 0.13.x changes the filesystem layout and config schema for custom providers
mkdir -p ~/.terraform.d/plugins/github.com/g-a-c/device42/0.0.1/darwin_amd64
go build -o ~/.terraform.d/plugins/github.com/g-a-c/device42/0.0.1/darwin_amd64/terraform-provider-device42_v0.0.1
# set the hostname for your Device42 instance
export D42_HOSTNAME=device42.company.com
# set the username in an environment variable and export it for child processes
export D42_USERNAME=you
# read your (non-echoed) password from the shell prompt and export it for child processes
read -s D42_PASSWORD
export D42_PASSWORD
# if your Device42 instance doesn't have a valid TLS certificate, enable "insecure mode"
export D42_INSECURE=true
# use main.tf to demo retrieving a value
cd tf_test/${version}
terraform plan -var=secret_id=<valid secret id>
This is currently difficult because I recently left the company where I had access to a Device42 instance. I have a trial version of 16.21.00.1610133596 (64 bit)
which this has been tested against (until the trial license runs out), and it seems to work OK, with some quirks:
- Device42 doesn't always return an actual error message, sometimes it's just
msg="", code=0
, which you would think means success (no error message, exit code0
). It doesn't mean success. - Device42 doesn't always return JSON (even if you specifically request it in headers), sometimes it's just a quoted string to say you don't have permissions. It's not clean, but it should be handled and spit out a sensible error message.
- Download from here
- Boot the VM and do whatever random network stuff you need to do to get it on the network
- The appliance may not be configured for DHCP by default but can be configured as such with the default console credentials (
device42
/adm!nd42
)
- The appliance may not be configured for DHCP by default but can be configured as such with the default console credentials (
- Once the web UI is available, you can log in with
admin
/adm!nd42
- Try to create a secret in the web UI; this should prompt you to set a passphrase to securely store credentials
- Set this passphrase and save it somewhere safe
- Add a new secret
- The minimum required fields are
username
andpassword
; if thelabel
field is populated then this is also retrieved - the auto-generated
id
is the key to retrieve it via Terraform
- The minimum required fields are
Example secret with `username` and `password` fields
» terraform plan -var=secret_id=1
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# null_resource.example will be created
+ resource "null_resource" "example" {
+ id = (known after apply)
+ triggers = {
+ "value" = "123456"
}
}
Plan: 1 to add, 0 to change, 0 to destroy.
Changes to Outputs:
+ output-password = "123456"
+ output-username = "test_username"
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
Example secret with `username`, `password` and `label` fields
» terraform plan -var=secret_id=2
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# null_resource.example will be created
+ resource "null_resource" "example" {
+ id = (known after apply)
+ triggers = {
+ "value" = "098765"
}
}
Plan: 1 to add, 0 to change, 0 to destroy.
Changes to Outputs:
+ output-label = "test_label"
+ output-password = "098765"
+ output-username = "test_username_2"
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
Example non-existent secret
» terraform plan -var=secret_id=3
Error: No secret was found
No secret exists in your Device42 instance with that ID
There is a public demo instance (https://swaggerdemo.device42.com
which ties in with the API reference at https://api.device42.com
) however as expected from a demo site, the data is reset periodically so there are no persistent passwords stored which could be referred to.
This would have been my motivation to also write resource_password.go
in order to create a password via a POST request, but the instance is not currently configured to accept password storage:
~ » curl -X POST -H "Authorization: Basic AA==" -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept: application/json' --data 'username=test&password=testPW&view_edit_users=guest,api_user' https://swaggerdemo.device42.com/api/1.0/passwords/
{"msg": "Please enter the passphrase first. Go to Tools > Settings > Password Security", "code": 2}
So there's no persistent data that could be used for testing, and no way to add a new password as part of the tests. I've sent an email to the Device42 support@
address to see if they could add an encryption passphrase to allow this demo instance to be testable, but won't hold my breath
- watch https://support.device42.com/hc/en-us/community/posts/360009940834-API-tokens-instead-of-user-pass in case D42 ever implements token-based API access for systems like Jenkins instead of just username/password auth
- support a "password command" env.var (i.e.
pass test/device42
to use passwordstore.org) rather than a password env.var - try to support inserting secrets
- this may be useful to generate a random value in Terraform using the
random
provider, then both use it as a password for a resource and also store it in Device42 in the same session
- this may be useful to generate a random value in Terraform using the