Open arun-gupta opened 6 years ago
Hi @arun-gupta -
I'm not sure that I completely follow the issue. It sounds like you are saying that:
When you build a VaultConfig
object, setting the token
field with a secret value pulled from an environment variable, everything works fine. However,
When you build a VaultConfig
object, and do NOT set a token
field value at all, then you experience a NPE when invoking Vault.logical().read(...)
.
Wouldn't this be expected behavior, though?
Assuming that my understanding is correct, the only unsupported use case I can see is where you are trying to read a path that is totally unprotected and world-readable, even without a token.
I've personally never seen that use case with Vault before. But if there's need for it, then I suppose I could null-check the token
value, and only put it on the request headers when it is non-null. Thus letting the operation fail due to a 403
from Vault, rather than a NPE in cases where a token really is necessary.
Before I make that change though, just wanted to confirm that I would be addressing the right thing.
This is now working as explained at https://github.com/aws-samples/aws-workshop-for-kubernetes/tree/master/config-secrets#secrets-using-vault.
Setup Vault as explained at:
https://github.com/arun-gupta/kubernetes-aws-workshop/tree/master/config-secrets#vault
Java application deployed as Pod in Kubernetes that reads secrets from Vault is:
https://github.com/arun-gupta/java-app-secrets/blob/master/src/main/java/org/examples/java/App.java
Pod spec is:
VaultConfig
initialized as shown below works and is able to retrieve the secrets:VaultConfig
initialized as shown below returns a NPE:Here is the NPE: