Background
As per the document given here, 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. One such case, considering the above limitation, is given below:-
So, for the very first time when you create the role, and when you don't set bind_secret_id explicitly, it goes as true by default even if secret_id_bound_cidrs is set or not, and your role gets created successfully. See below the screenshot for one such example where we are creating a role with the name my-test-role and not providing any values for attributes bind_secret_id and secret_id_bound_cidrs:
$ vault write auth/approle/role/my-test-role \
token_ttl=1h token_max_ttl=4h
Success! Data written to: auth/approle/role/my-test-role
$ vault read auth/approle/role/my-test-role
Key Value
--- -----
bind_secret_id true
local_secret_ids false
secret_id_bound_cidrs <nil>
secret_id_num_uses 0
secret_id_ttl 0s
token_bound_cidrs []
token_explicit_max_ttl 0s
token_max_ttl 4h
token_no_default_policy false
token_num_uses 0
token_period 0s
token_policies []
token_ttl 1h
token_type default
On the other hand, if you set it to false and there are no secret_id_bound_cidrs it would throw an error saying "at least one constraint should be enabled on the role" because at least one of bind_secret_id or secret_id_bound_cidrs is required to be set to secure the approle logins, and this is the default nature of the Vault's approle plugin.
Having said that, even the modification of bind_secret_id from true to false will only work if you set secret_id_bound_cidrs alongside. If you try changing it to false without having secret_id_bound_cidrs you'll see it would throw the same error again. See below the screenshot for the same: -
$ vault write auth/approle/role/my-test-role \
token_ttl=1h token_max_ttl=4h bind_secret_id=false
Error writing data to auth/approle/role/my-test-role: Error making API request.
Namespace: admin/
URL: PUT https://vault-cluster-std-small-public-vault-5407b127.ad9201ea.z1.hashicorp.cloud:8200/v1/auth/approle/role/my-test-role
Code: 500. Errors:
* 1 error occurred:
* at least one constraint should be enabled on the role
Solution
secret_id_bound_cidrs is a comma-separated string or list of CIDR blocks; if set, specifies blocks of IP addresses that can perform the login operation, and if our requirement is that we don’t want any such restriction on IP addresses and we like to set bind_secret_id to false so that no secret_id is required when logging in using this AppRole, we can achieve this by setting them such as:-
$ vault write auth/approle/role/my-test-role \
token_ttl=1h token_max_ttl=4h bind_secret_id=false secret_id_bound_cidrs="0.0.0.0/0"
Success! Data written to: auth/approle/role/my-test-role
$ vault read auth/approle/role/my-test-role
Key Value
--- -----
bind_secret_id false
local_secret_ids false
secret_id_bound_cidrs [0.0.0.0/0]
secret_id_num_uses 0
secret_id_ttl 0s
token_bound_cidrs []
token_explicit_max_ttl 0s
token_max_ttl 4h
token_no_default_policy false
token_num_uses 0
token_period 0s
token_policies []
token_ttl 1h
token_type default
We can also implement this using Terraform Vault provider and here is how the main.tf
will look like:-
terraform {
required_providers {
vault = {
source = "hashicorp/vault"
version = "3.20.0"
}
}
}
variable login_username {}
variable login_password {}
provider "vault" {
address = "https://vault-cluster-XXX-XXX-public-vault-XXXXXXXXXXX.hashicorp.cloud:8200"
namespace = "admin"
auth_login {
path = "auth/userpass/login/${var.login_username}"
parameters = {
password = var.login_password
}
}
}
resource "vault_auth_backend" "approle" {
type = "approle"
}
resource "vault_approle_auth_backend_role" "role" {
backend = vault_auth_backend.approle.path
role_name = "my-role"
token_policies = ["default"]
token_ttl = 300
secret_id_ttl = 60
token_num_uses = 3
secret_id_num_uses = 3
bind_secret_id = false
secret_id_bound_cidrs = ["0.0.0.0/0"]
}
#resource "vault_approle_auth_backend_role_secret_id" "id" {
# backend = vault_auth_backend.approle.path
# role_name = vault_approle_auth_backend_role.my-role.role_name
#}
resource "vault_approle_auth_backend_login" "login" {
backend = vault_auth_backend.approle.path
role_id = vault_approle_auth_backend_role.role.role_id
# secret_id = vault_approle_auth_backend_role_secret_id.id.secret_id
}
As you can see above, secret_id_bound_cidrs = ["0.0.0.0/0"]
so that there are no restrictions from the CIDR perspective as well (but you can put the restriction as you like), plus the bind_secret_id
is set to false
as well.
The resource vault_approle_auth_backend_role_secret_id
is commented out because you don't need a secret_id
to log in using this role because bind_secret_id
is set to false
, and that is why secret_id = vault_approle_auth_backend_role_secret_id.id.secret_id
in the resource vault_approle_auth_backend_login
is also commented out. These need to be uncommented when bind_secret_id
is set to true
Here is what terraform.tfstate
captured when we applied the said main.tf
and can see that we've received the client_token
:
{
"version": 4,
"terraform_version": "1.5.7",
"serial": 63,
"lineage": "82a0bead-xxxxxxxx-xxxxxxxx-a7d35a",
"outputs": {},
"resources": [
{
"mode": "managed",
"type": "vault_approle_auth_backend_login",
"name": "login",
"provider": "provider[\"registry.terraform.io/hashicorp/vault\"]",
"instances": [
{
"schema_version": 0,
"attributes": {
"accessor": "uiyOPxxxxxxx-xxxxxxxxTjek",
"backend": "approle",
"client_token": "hvs.CAESID0m-B4LU08fxxxxxxxxxx-xxxxxxxxxxxxxxxOHhxxxxxwY",
"id": "uiyOPxxxxxxx-xxxxxxxxTjek",
"lease_duration": 0,
"lease_started": "2023-09-23T11:30:49+05:30",
"metadata": {},
"namespace": null,
"policies": [
"default"
],
"renewable": true,
"role_id": "89704cb4-xxxxxxxxxxxxx-5dbdaxxxxxxxabc",
"secret_id": null
},
"sensitive_attributes": [],
"private": "bnxxxxxxx=",
"dependencies": [
"vault_approle_auth_backend_role.role",
"vault_auth_backend.approle"
]
}
]
},
{
"mode": "managed",
"type": "vault_approle_auth_backend_role",
"name": "role",
"provider": "provider[\"registry.terraform.io/hashicorp/vault\"]",
"instances": [
{
"schema_version": 0,
"attributes": {
"backend": "approle",
"bind_secret_id": false,
"id": "auth/approle/role/my-role",
"namespace": null,
"role_id": "89704cb-xxxxxxxxxx-eeabc",
"role_name": "my-role",
"secret_id_bound_cidrs": [
"0.0.0.0/0"
],
"secret_id_num_uses": 3,
"secret_id_ttl": 60,
"token_bound_cidrs": null,
"token_explicit_max_ttl": 0,
"token_max_ttl": 0,
"token_no_default_policy": false,
"token_num_uses": 3,
"token_period": 0,
"token_policies": [
"default"
],
"token_ttl": 300,
"token_type": "default"
},
"sensitive_attributes": [],
"private": "bxxxxxxxx=",
"dependencies": [
"vault_auth_backend.approle"
]
}
]
},
{
"mode": "managed",
"type": "vault_auth_backend",
"name": "approle",
"provider": "provider[\"registry.terraform.io/hashicorp/vault\"]",
"instances": [
{
"schema_version": 1,
"attributes": {
"accessor": "auth_approle_32xxxxxx4",
"description": "",
"disable_remount": false,
"id": "approle",
"local": false,
"namespace": null,
"path": "approle",
"tune": [],
"type": "approle"
},
"sensitive_attributes": [],
"private": "eyxxxxxxxxxxxxxxxxxxxifQ=="
}
]
}
],
"check_results": null
}