# Actions/Hashicorp Vault integration

**URL:** <https://forum.gitea.com/t/actions-hashicorp-vault-integration/10982>\
**Category:** Actions\
**Created:** [March 18, 2025, 6:42pm UTC](https://forum.gitea.com/t/actions-hashicorp-vault-integration/10982 "2025-03-18T18:42:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![scubbo](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/scubbo/32/3331_2.png) [@scubbo](https://forum.gitea.com/u/scubbo)\
**Post date:** [March 18, 2025, 6:42pm UTC](https://forum.gitea.com/t/actions-hashicorp-vault-integration/10982/1 "2025-03-18T18:42:13Z")

</div>

Does anyone have a working implementation of a Gitea Action workflow fetching secrets from Hashicorp Vault? There’s an existing [GitHub Action](https://github.com/hashicorp/vault-action) which I’ve used to great effect at $DAY\_JOB (with GitHUB actions, not Gitea Actions), but I can’t get my head around how to authenticate to Vault from GiteaActions:

- [JWT with GitHub OIDC Tokens](https://github.com/hashicorp/vault-action?tab=readme-ov-file#jwt-with-github-oidc-tokens) doesn’t seem feasible as [Gitea cannot currently act as an OIDC provider](https://github.com/go-gitea/gitea/issues/26383)
- [AppRole-](https://github.com/hashicorp/vault-action?tab=readme-ov-file#approle), [Userpass-](https://github.com/hashicorp/vault-action?tab=readme-ov-file#userpass), or [Token](https://github.com/hashicorp/vault-action?tab=readme-ov-file#token)-based authentication would require provision of static secrets, which defeats the purpose of dynamic secret provision.
- [GitHub Auth](https://github.com/hashicorp/vault-action?tab=readme-ov-file#github) is presumably not available (though I admit I haven’t tried it!)
- [Kuberenetes auth](https://github.com/hashicorp/vault-action?tab=readme-ov-file#kubernetes) _could_ work, though I don’t think that would provide the ability for different repo’s Actions to have access to differing Vault Roles - this would use the `serviceAccountName` for the hosted `act-runner`s, which would not differentiate based on source repo.
- [JWT with OIDC Provider](https://github.com/hashicorp/vault-action?tab=readme-ov-file#jwt-with-oidc-provider) and [LDAP](https://github.com/hashicorp/vault-action?tab=readme-ov-file#ldap) are probably feasible, but require a whole external system.

---

<div class="post-metadata">

**Author:** ![ben-freke](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/ben-freke/32/7001_2.png) [@ben-freke](https://forum.gitea.com/u/ben-freke)\
**Post date:** [July 19, 2025, 6:17pm UTC](https://forum.gitea.com/t/actions-hashicorp-vault-integration/10982/2 "2025-07-19T18:17:54Z")

</div>

I’m hitting exactly the same problem. Did you come up with a resolution for this?

---

<div class="post-metadata">

**Author:** ![ben-freke](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/ben-freke/32/7001_2.png) [@ben-freke](https://forum.gitea.com/u/ben-freke)\
**Post date:** [July 19, 2025, 6:36pm UTC](https://forum.gitea.com/t/actions-hashicorp-vault-integration/10982/3 "2025-07-19T18:36:57Z")

</div>

I’ve just spent time reading up on the various Issues / PRs associcated with this, so glad it’s got a milestone attached to it now and thanks for all your work!

As that milestone is set for August of this year, I’m interested as to what your workaround is for the meantime? The solution I’ve “settled” on until OIDC comes along is using an AppRole and some quirkly policy combinations to minimise any potential damage, accepting I cannot make it perfect.