#vault (2021-10)

vault Discussions related to Hashicorp Vault

2021-10-28

2021-10-27

 avatar
04:30:14 PM

I use dynamic secret engines in vault

2021-10-18

David avatar
David

Has anyone played around with having Github codespaces authenticate to Vault? They seem to come with Github PATs, but the PATs cannot read organization information, meaning I don’t think they can login to vault by default

Zachary Loeber avatar
Zachary Loeber

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

GitHub - Auth Methods | Vault by HashiCorp attachment image

The GitHub auth method allows authentication with Vault using GitHub.

Zachary Loeber avatar
Zachary Loeber

How are they authing to codespaces?

Zachary Loeber avatar
Zachary Loeber

(sry, not a codespaces guru)

David avatar
David

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

Zachary Loeber avatar
Zachary Loeber

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.

Vault Auth using GitHub Personal Tokens - Wahl Network

Check out how to quickly and easily use GitHub Personal Access Tokens to authenticate and access a HashiCorp Vault instance.

Zachary Loeber avatar
Zachary Loeber

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?)

Zachary Loeber avatar
Zachary Loeber

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

2021-10-12

mikesew avatar
mikesew

Q about vault-token lookups: does anybody know what permission is required to actually lookup your-own token data? Right now, I tried logging in with a test app-role account, but it cant even look up or renew its own token.

# LOGIN using the approle app-spa-npd-jenkins-readonly:
vault write auth/approle/login   role_id=***   secret_id=***

URL: GET <https://vault.lllint.com/v1/auth/token/lookup-self>
Code: 403. Errors:
* permission denied
Zachary Loeber avatar
Zachary Loeber

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

Zachary Loeber avatar
Zachary Loeber

plus, where are you sourcing your VAULT_TOKEN?

Zachary Loeber avatar
Zachary Loeber

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

Zachary Loeber avatar
Zachary Loeber

approle sucks

Zachary Loeber avatar
Zachary Loeber

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

mikesew avatar
mikesew

@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.

mikesew avatar
mikesew

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.

Zachary Loeber avatar
Zachary Loeber

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.

Zachary Loeber avatar
Zachary Loeber

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

Zachary Loeber avatar
Zachary Loeber

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

Zachary Loeber avatar
Zachary Loeber

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)

Zachary Loeber avatar
Zachary Loeber

Are there possibly cidr based restrictions on your approle?

Zachary Loeber avatar
Zachary Loeber

that would certainly be an issue if so

Zachary Loeber avatar
Zachary Loeber

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

Zachary Loeber avatar
Zachary Loeber

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

mikesew avatar
mikesew

@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

Zachary Loeber avatar
Zachary Loeber

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.

mikesew avatar
mikesew

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.

Zachary Loeber avatar
Zachary Loeber

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.

Zachary Loeber avatar
Zachary Loeber

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

1
Zachary Loeber avatar
Zachary Loeber

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

    keyboard_arrow_up