#vault (2021-10)

I think ensuring that the approle is assigned at least the ‘default’ policy should do it

plus, where are you sourcing your VAULT_TOKEN?

looks like you cannot login with the current token to do the write to approle to create the new vault auth token

approle sucks

why they use it in almost every practical example is beyond me

@Zachary Loeber: that’s an interesting observation, i’m having questions about approle myself. i was only trying to follow the best practice, and it appears that “service account == use an approle” according to docs/tutorials. the problem is that somewhere in the global policy, my vault admin has DENIED self-lookups . i was trying to see if I could specify it directly.

my coworkers appear to prefer using token policies instead. I’m trying to see if I can follow that lead, and it seems simpler to follow.

denying self-lookup capability gives very little reward, why would that be the case? The only thing I can think of that it ‘may’ help is preventing cicd pipelines from spitting out unmasked token and token accessor info. It is literally part of the default policy.

Do you have any other form of auth to test? oidc/cert/et cetera?

token based policies are how all the guides would have you do things as well. It works very well and is really just like directly assigning policies to roles

When the internal vault offering matures one tends to move to entity groups to assign policies though (just another personal observation, not really applicable here)

Are there possibly cidr based restrictions on your approle?

that would certainly be an issue if so

I’m curious how you are made to request new roles in vault?

your admin have some kind of git based pull request process in a centralized project?

@Zachary Loeber sorry for delayed response.

• yes, we have a shared vault repo where we are instructed to create policy files and terraform .tf files to reference those policies.

• yes, the app-role is given a CIDR whitelist via a terraform vairable (for example, they have a value which covers the subnets of our CI/CD jenkins nodes)

• i agree that disabling sefl-lookup/introspection is needlessly holding people back. end-users/practitioners should be able to lookup/verify what they had tried to submit in their PR

I am also quite tardy in my responses it seems . Thanks for even answering my goofy questions. My curiosity stems from work I’ve done in the last year. I’ve taken a similar approach for an internal vault as a service offering but have generalized all the team vault scaffolding and requirements into a single yaml manifest (per team) that project owners own/update/PR approve that then process in relatively complex CICD provisioning pipelines on the backend. The idea of letting people write their own vault policies is kinda bonkers to me though. Your team must be using sentinel or OPA (or something similar) on your end to restrict the pathing of such policies or you could just give yourself lookup rights.

Just to continue a thread, vault team provided template files for policies, teams, and even terraform .tf’s which created the resources. We copy, find/replace with our app-name, and PR. Honestly I find there’s too much room for error as a “end-user” of that service. They do have sentinel but PRs often break things.

Interesting, we were originally doing something similar for each kind of vault secret engine being its own git repo that could deploy to multiple environments. this was paired with an auth repo to assign the permissions. Everything was PR driven but it meant that the number of touch points for dev and app teams was voluminous (If you deployed one secret engine to 4 environments and setup access to that engine it meant that no less than 8 files across 2 repos would need modification. This would be the simplest use case too). I re-engineered it down to a single repo and a declarative yaml file that could be used to describe a team’s secret engines, auth roles, and more. This then produces the myriad of terraform files needed by the downstream provisioning pipelines automatically. It is still quite complicated on the backend but the end user experiences is dramatically simplified.

My only major issue with this code factory I’ve created is managing shared terraform state.

We also use sentinel but mostly for limiting the kv keys and paths teams are allowed to use

wouldn’t you still use the github auth integration? https://www.vaultproject.io/docs/auth/github

How are they authing to codespaces?

(sry, not a codespaces guru)

No worries, I appreciate the thoughts.

My understanding is that: • Developers authenticate to Codespaces through their github credentials, but their credentials are not available inside the codespace • Instead, Github provisions a temporary PAT inside the codespace to perform git operations, but that PAT does not have the organization:read scope that Vault needs to verify a PAT to login with

https://wahlnetwork.com/2020/02/10/vault-auth-using-github-personal-tokens/ <– This is as good as I could find on vault auth specifically with a github PAT.

It would still likely require some kind of init script to use the PAT to auth and pull in whatever secrets (local encrypted github sourced secrets should also still be in the codespaces session though, perhaps just create manual dev level secrets in that manner and have prod still use vault via gitlab actions integration?)

Vault is awesome when what you are using actually integrates with it heh