I have a docker-compose that setup HashiCorp Vault and Vault Agent services.

Then I have a script that setup a Transit engine and a key.
The script creates the policy to the transit key and add it to the role of the token.
Using the token as credential I need to get the transit key.

I get the error 403 "1 error occurred:nt* permission deniednn".
With a wrong token I have 403 "permission denied", also using the token I’m able to login in the UI. That proves the token is working as credentials.
Using the rootToken I get the 200 success result.
So, problem seems related to permissions/policies.

In the Docker compose I use this to set the Agent:
command: [ 'vault', 'agent', '-config=/volumes/vault-agent-localhost/config.txt']

config.txt:

pid_file = "/volumes/vault-agent/pidfile"

vault {
  address = "http://vault:8200"
}

auto_auth {
  method {
    type = "approle"
    config = {
      role_id_file_path                   = "/volumes/vault-agent/role-id"
      secret_id_file_path                 = "/volumes/vault-agent/secret-id"
      remove_secret_id_file_after_reading = false
    }
  }

  sink {
    type = "file"
    config = {
      path = "/volumes/vault-agent/token"
    }
  }
}

the seatup.sh script:

export VAULT_ADDR='http://127.0.0.1:8210'
export VAULT_TOKEN='rootToken'


# setup AppRole
vault auth enable approle


# update is required to call "sign" !!
policy='path "transit-local/*" { capabilities = ["read", "update"] } '

# create policy ("-" mean it read from std-in)
echo $policy | vault policy write myapp -

vault write auth/approle/role/my-role 
    role_id="my-role" 
    token_policies="myapp" 
    token_ttl=120m 
    token_max_ttl=120m 
    secret_id_num_uses=0

# this solved the error: error getting path or data from method: error="no known secret ID"
vault write -f -field=secret_id auth/approle/role/my-role/secret-id > volumes/vault-agent/secret-id


# Create the transit engine (if not exists)
vault write sys/mounts/transit-local type=transit path=transit-local

# create a new Ed25519 key 
key_name="my-key-ed25519"
vault write -f transit-local/keys/$key_name type=ed25519

If I login the UI with rootToken I can see the transit-local path, and the key inside it.
If I login the UI with generated token I cannot see the transit-local path.

In the UI Policies section, I can see “myapp” and if I open it I can see the policies:

path "transit-local/*" { capabilities = ["read", "update"] } 

What is missing here ? why that token is not getting the permission?