-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Closed
Labels
Description
Module
Vault
Proposal
In the VaultContainer there's this little method:
@Override
protected void containerIsStarted(InspectContainerResponse containerInfo) {
addSecrets();
runInitCommands();
}This works fine for the most part, but I recently had a situation where I needed to run the kv (v1) engine on the postgresql secret path, so I added this to my config:
PostgreSQLContainer<?> VAULT_CONTAINER = new VaultContainer<>("hashicorp/vault:1.11.2")
.withVaultToken("supersecret-vault-token")
.withInitCommand(
"secrets enable transit",
"write -f transit/keys/my-key",
"secrets enable -path=postgresql kv")
.withSecretInVault("postgresql/test", "username=test", "password=test")
.start();It doesn't look as though existing secrets are affected by the secrets enable -path=postgresql kv, however. It does work if I comment out the .withSecretsInVault(...) line and add this monstrosity after the block above, which is more or less the same logic you'll find inside the addSecrets()-method:
try {
Container.ExecResult execResult = VAULT_CONTAINER.execInContainer(
"/bin/sh", "-c",
"vault kv put postgresql/test username=test password=test");
String result = execResult.getStdout();
if (!result.contains("Success!")) {
throw new IllegalStateException(execResult.getStderr());
}
} catch (Exception exception) {
throw new IllegalStateException("Failed to store secret in Vault", exception);
}So my suggestion is to adjust the implementation of containerIsStarted(InspectContainerResponse) to this:
@Override
protected void containerIsStarted(InspectContainerResponse containerInfo) {
runInitCommands();
addSecrets();
}Reactions are currently unavailable