Unclear roles pattern matching

[Guchman]

Hi, I spend a lot of time trying to configure gatekeeper properly. Im stuck with role's policies configuration.
This is my policies configuration:

{
        "mesos:*:*": {
                "roles": [
                        "api"
                ],
                "num_uses": 30
        }
}

But when Im trying to get token:

sudo curl -X POST -d"{\"task_id\":\"abm_abm-api.e902c261-94ba-11e8-8961-062024e1b273\", \"scheduler\": \"mesos\", \"role\":\"api\"}" 'http://abmtest:9201/token'

I've got an error instead:

{"unsealed":true,"error":"Your task does not have permission to use this role."}

I have "default" and "api" roles configured in the vault.
When I make my token request without "role" tag:

sudo curl -X POST -d"{\"task_id\":\"abm_abm-api.e902c261-94ba-11e8-8961-062024e1b273\", \"scheduler\": \"mesos\"}" 'http://abmtest:9201/token'

then request goes with "default" role and I could get token.
I've tried "*", "mesos:*:*", "mesos:marathon:*", "mesos:marathon:abm_*" keys but no one works for me. Where Im going wrong and maybe you should clarify documentation or logs output? Thanks!

[nemosupremo]

The wildcard can only appear at the end of your policy name. So mesos:* would be the appropriate name in your policy.

According to your setup here, however, since only the "api" role is listed in your policy configuration, then that means the token you get will have the api role. I don't see how you could get a default role token if "default" isn't anywhere in your policy configuration. Can you run gatekeeper policy? This will show that gatekeeper believes the current policy should be.

[Guchman]

I'd try "mesos:*" also. Same result. That's my config returned by "policy" method:

time="2018-07-31T16:14:18Z" level=info msg="Loaded policies. 1 total policies."
{
        "mesos:*": {
                "roles": [
                        "api"
                ],
                "num_uses": 30
        }
}

my curl:

sudo curl -X POST -d"{\"task_id\":\"abm_abm-api.05be9800-94dd-11e8-8961-062024e1b273\", \"scheduler\": \"mesos\", \"role\":\"api\"}" 'http://test:9201/token'                  

response:

{"unsealed":true,"error":"Your task does not have permission to use this role."}

As I could see in vault logs it's not go for api role auth, only gatekeeper auth(successfully).
But when I try to call gatekeeper without role:

sudo curl -X POST -d"{\"task_id\":\"abm_abm-api.d6758851-94dd-11e8-8961-062024e1b273\", \"scheduler\": \"mesos\"}" 'http://abmtest:9201/token'

I could get token.

{"unsealed":true,"token":"0b7e3f18-5945-f0d4-6955-cb382ccd49c2","ttl":"1h40m0s","vault_addr":"http://test:8200/"}

And there is also "read" request for path "auth/approle/role/default/secret-id" in Vault logs, not "api".

Where I get wrong?

[nemosupremo]

The only thing that makes sense to me is, did you previously load a policy with gatekeeper that had a default role? The policy in Gatekeeper might be stale, and you may need to reload the policy. Run the command:

GATEKEEPER_ADDR=http://abmtest:9201 gatekeeper policy reload

And try again. The issue here could be that the policy in Gatekeeper's memory is stale. Even if you update the policy in Vault, you need to "refresh" gatekeeper so it loads the new policy.

[Guchman]

You're right! "policy reload" helped me. But it's still a little bit tricky. There is no info in output of "policy" command or special mention documentation. I'd expect that "policy update" should be enough.
And I expect that "policy" command returns policies that actually used by gatekeeper right now.

[Guchman]

Also I wonder why "api_*" not work for "api_1234" but "*" pattern works for me

[nemosupremo]

To match something like api_1234 with api_*, check out the regexp matcher in #77.