OIDC entity facing issues in polices

[agaur123]

Hey team,

I have created a policy to access the secret, policy and access for my entity via OIDC,
the policy which i wrote is

path "/secret/*" {
   capabilities = ["sudo", "create", "list", "read", "update", "delete"]
}
path "secret/data/IK" {
   capabilities = [ "create", "list", "read", "update", "delete" ]
}
path "secret/*" {
   capabilities = ["create", "sudo", "list", "read", "update", "delete"]
}
# Mount the OIDC auth method
path "sys/auth/oidc" {
  capabilities = [ "create", "read", "update", "delete", "sudo" ]
}

# Configure the OIDC auth method
path "auth/oidc/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

# Write ACL policies
path "sys/policies/acl/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

# List available secrets engines to retrieve accessor ID
path "sys/mounts" {
  capabilities = [ "read" ]
}

path "sys/internal/ui/mounts/*" {
  capabilities = ["read", "create", "update", "list", "sudo", "delete"]
}

path "/v1/sys/internal/ui/mounts/*" {
  capabilities = ["read", "create", "update", "list", "sudo", "delete"]
}

there are some path which can be wrong, please avoid that,

Command running to write this policy

1. vault policy write dev dev.hcl
   Then assigning to the entity
2. vault write identity/entity name="entity_id" policies="dev"
   When i am trying to login via UI, i can see the secrets ,policies and access tab,
3. In Secrets tab, i can see the Underline path, but only for once, after that it shows this
   
   
4. In Access tab , getting this issue
   
   
5. In Policies getting this
   
   

P.S: I am a beginner in Vault , if you have any suggestions just do let me know.

[jeffsanicola]

Can you run a vault policy read dev and see if it displays the same policy you’ve attempted to upload?

[jeffsanicola]

Also, can you share your setup for your OIDC role? Redact any sensitive bits, of course.

[agaur123]

@jeffsanicola

1. The Output for Vault policy read dev is same which i posted above.
2. So for OIDC Config ran this ,

vault write auth/oidc/config \
    oidc_discovery_url="https://gitlab.com" \
    oidc_client_id="" \
    oidc_client_secret="" \
    default_role="codebards" \
    bound_issuer="https://gitlab.com"

3. And after creating the role codebards, this is detail of it

[jeffsanicola]

OK - this provides a bit more context. Have you tried going through GitLab’s OIDC setup guide for Vault? Vault Authentication with GitLab OpenID Connect | GitLab

Also, I’m assuming your OIDC ID/Secret are redacted and not blank. But if they are blank those will likely need to be populated.

I’ve not configured GitLab/OIDC myself but based on step 4 you might have some inconsistencies with their guidance. oidc_scopes should be "openid" for instance, and supply a bound_claims value (see linked guide for an example). Also, I think your bound_issuer in the auth method config should just be the root URL without any http or https scheme attached.

Try getting the policy assignment to work on the OIDC role itself first then work toward the identity entity/groups as that adds another layer of complexity that you don’t need to deal with until you get the role assignment sorted out.

[agaur123]

@jeffsanicola ,

1. I have followed the same link to connect via OIDC
2. OIDC ID and Secret are the same which are in gitlab Application for OIDC
3. OIDC scope i have tried with email, but i can try with openid too
4. bound_issuer and bound_claims will do that change.
5. Sure working on role rather than entity or group will make that change

[aram]

Well for one thing you’re trying to do too many things at once and it’s confusing things.

Let’s just take the secret access.

I’m going to assume it’s a KV v2, since you don’t mention the engine, and the path is “secret”.

1 - Don’t repeat paths with more detail after, Vault is a permission system with deny-all. Every time you add a policy you simply add capabilities.

For the UI access you need two policies:

policy "secret/data/*" {
   capabilities = [ "read", "list" ]
}
path "secret/metadata/mysecret" {
  capabilities = ["read"]
}

You need the metadata path for the UI to function properly because of the versioning.

2. The other note I want to mention that is your policy names don’t seem to match, so I’m not sure if they’re being applied to your auth token or not.

vault token lookup <token> 

will show you the policies both at entity, auth, and group (if any) levels. Check those to make sure you have access.

3. I hope you’re testing because you need to be more discerning with the policies you’re using.

4. No user should have full access to sys/internal/ui/mounts. auth paths are not authenticated themselves otherwise it would be vicious circle to be able to authenticate.

5. /v1 should never be part of your policy, that’s an internal route.

6. vault token capabilities <token> <path> is your friend. You can use to see what the result of the policy is.
   token capabilities - Command | Vault by HashiCorp

7. Don’t use the UI as a measuring stick for access, use the CLI. If that works then the policy worked, if you need the UI access to work then you can add more policies but get your base access policy first.

[agaur123]

Hey aram, thanks for commenting

1. But when i am trying to connect via CLI , i am facing issue with this
   
   

Let suppose my IP is 3.144.188.232 then i am trying to replace it and put in the redirectURIs, then also it’s not working.
2. If i am giving this policy

# Allow a token to look up its own capabilities on a path
path "sys/capabilities-self" {
    capabilities = ["update"]
}

path "secret/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

# Manage secrets engines
path "sys/mounts/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

What do you think should be output of this, because even after applying this, when i am again redirecting to secrets page it give me 403 error of /sys/internal/mounts. I am not able to understand.

[aram]

Your callback can’t be your localhost, something is misconfigured.