Question about approle constraints

I am a newbie and I am learning how to use authentication with approle. There is something I don’t understand and I might be messing up.
My environment is all on-premises.
I created a module in terraform to be used by an application called gaia that creates a graphical interface to facilitate the creation of VM’s for those who don’t know terraform. This module authenticates on vmware vsphere.
I created an approle that should allow only gaia’s server to access the vsphere secrets using the parameters vsecret_id_bound_cidrs and token_bound_cidrs as restrictions. I manually generated a token and included it in the terraform script. The problem is that I can run this script from any device.
There is something about the configuration or the approle concept that I don’t understand yet that is causing the ip restrictions to be ignored
Below are my configuration files:

Approle for Terraform

vault write auth/approle/role/terraform \
      bind_secret_id=false \
      enable_local_secret_ids=false \
      token_bound_cidrs="","gaia_server_ip/32" \
      token_num_uses=0 \
      token_ttl=1h \
      secret_id_num_uses=0 \
      token_max_ttl=3h \
      token_type=default \
      period="" \

Terraform policy

path "secret/vmware/vcenter" {
  capabilities = [ "read", "list" ]

path "auth/approle/role/terraform/role-id" {
  capabilities = [ "read" ]

What am I missing? Any help is welcome!

ps: I am not a native English speaker. So if something is not clear just let me know.

I don’t know understand why you said “I generated a token”.
An approle is a roleid + secretid. If you use a token in your application, you do not perform a login request, so, all bound_cidrs are not applicable. The bound_cidrs is only when you perform a login on the approle path.

So my problem was conceptual. I thought that the token was still needed to terraform despite the roleid. Sorry. It was just a beginner’s doubt. Following your point I re read the doc and find how to insert approle role id in vault provider block using auth_login parameter. Problem solved!