Add kubernetes auth method

[atheiman]

#177 + unit tests

[hashicorp-cla]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

1 out of 2 committers have signed the CLA.

• atheiman
• ls-brentsmith

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[tecnobrat]

Looks like your tests are failing here @atheiman

[off-by-some]

I'd really like to make use of this feature however it looks like @atheiman and @ls-brentsmith are no longer actively working on this PR. I'd like to continue work on this and create another PR with similar functionality and have it merged upstream, however i'm not sure on whether it would end up in a limbo-like state with the CLA checks.

Any suggestions here as to what i should do here?

[Patricol]

@rho-bit (and future readers) you'd have to rewrite the parts that @ls-brentsmith wrote, because he hasn't signed the CLA. @atheiman 's contributions are usable because he did sign the CLA. You (hypothetical PR-opener) would also need to sign the CLA.

[rmcclaincf]

This is badly needed and has been for years now. Everyone is on kubernetes.

I'm not sure how you'd rewrite the parts [ls-brentsmith] wrote as it's just a few lines of super straightforward code that wouldn't be written another way.

[carlwiedemann]

Hi everyone,

I'm working with a team on a project that is leveraging a private fork of this gem which contains cherry-picked commits from this branch.

My team is interested to get away from this private fork. We would like to contribute these k8s features back to the mainline here. We can see that other folks continue to have the same needs as we do.

Our private fork was an artifact of former employees, and we are not really interested in maintaining it. We would much rather contribute here, and we are happy to sign the CLA.

If we open up a separate PR for this work, and we sign the CLA, could this be a welcomed feature to this project?

CC'ing folks who I believe may have some say as potential maintainers (i.e. GitHub bio mentions they work for HashiCorp) @benashz @digivava @chrisarcand.

Please redirect this comment to others if they are more relevant stakeholders here. Thank you so much in advance!

[digivava]

Thanks for the context and apologies for the inconvenience as HashiCorp figures out how to maintain this gem more regularly. I'll pass this over to the @hashicorp/vault-devex folks who have recently taken charge of the official client libraries.

[carlwiedemann]

@digivava Thanks for the prompt response! Looking forward to helping out. I'll keep my team up-to-date and keep an eye out for further conversation here with the devex folks.

[yoda]

Any movement on this?

[digivava]

Apologies for the delay on this folks, we are unfortunately in the process of finding new ownership for this library again, and Ruby expertise on the current Vault team is limited. All I can do at this time is recommend getting a new PR in with a signed CLA (if the original PR authors have abandoned this), and I can pass the torch to @mladlow , who is working on finding new ownership for the gem.

That team would be the ones to review. Sorry for the long waits causing you to fork.

@mladlow This seems like a good "first PR" to point out for the new ownership team to tackle, given its impact and straightforwardness.

[diclophis]

@mladlow @digivava any luck finding new ownership for this gem?

Is this something someone could volunteer for?

[mladlow]

@diclophis we've mad a small amount of progress but are still working on this.

[diclophis]

@mladlow that is good to hear... FWIW I was able to patch this change onto a test deployment and it does successfully authenticate via the mounted k8s service account token file (once you have setup all of the other parts of course as noted in the vault documentation).

I did not test the authentication mechanism at any extreme scale nor did I test any sort of expiration / short-lived-expiry features that there might be associated with using the k8s service token.

[mladlow]

Hey @diclophis I wanted to give you a heads up that we've posted a deprecation announcement of this resource and the vault-rails gem.

If someone is interested in maintaining a Community-supported library, we have a number of them linked on our documentation, and we're asking people to submit issues to have replacement Ruby community-supported resources added to the page.

[diclophis]

Thanks... This is a bit disheartening, ruby/rails is quite relevant of an application platform still... and vault seems to still be the leading centralized secret store provider... we would be losing significant value if this project were completely abandoned...

[mladlow]

@diclophis Understood. We will continue to support it for a year, which is our standard deprecation announcement window.

[diclophis]

If we could close this issue out that would be nice so that it is removed from my list of pending items to review.