NullPointerException if Vault token is specified during initialization

[arun-gupta]

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:

apiVersion: v1
kind: Pod
metadata:
  name: java-app-secrets
spec:
  containers:
  - name: java-app-secrets
    image: arungupta/java-app-secrets:latest
    env:
      - name: VAULT_ADDR
        value: http://ec2-54-237-223-40.compute-1.amazonaws.com:8200
      - name: VAULT_TOKEN
        value: 4e93b3c6-c459-f166-e7e9-6c48044cfdb6
  restartPolicy: Never

VaultConfig initialized as shown below works and is able to retrieve the secrets:

final VaultConfig config = new VaultConfig()
                .address(System.getenv("VAULT_ADDR"))
                .token(System.getenv("VAULT_TOKEN"))
                .sslConfig(new SslConfig().verify(false).build())
                .build();

VaultConfig initialized as shown below returns a NPE:

final VaultConfig config = new VaultConfig()
                .address(System.getenv("VAULT_ADDR"))
                .sslConfig(new SslConfig().verify(false).build())
                .build();

Here is the NPE:

Exception in thread "main" com.bettercloud.vault.VaultException: java.lang.NullPointerException
    at com.bettercloud.vault.api.Logical.read(Logical.java:84)
    at org.examples.java.App.main(App.java:26)
Caused by: java.lang.NullPointerException
    at java.net.URLEncoder.encode(URLEncoder.java:204)
    at com.bettercloud.vault.rest.Rest.header(Rest.java:173)
    at com.bettercloud.vault.api.Logical.read(Logical.java:56)
    ... 1 more

[steve-perkins]

Hi @arun-gupta -

I'm not sure that I completely follow the issue. It sounds like you are saying that:

1. When you build a VaultConfig object, setting the token field with a secret value pulled from an environment variable, everything works fine. However,

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

[arun-gupta]

This is now working as explained at https://github.com/aws-samples/aws-workshop-for-kubernetes/tree/master/config-secrets#secrets-using-vault.