Provider should wait for the access token file to exist

[kgilpin]

When summon-conjur is used in a Pod scenario, the Conjur access token is provided as a file path.

This provider should wait for the file to exist. This will give a sidecar container time to login and obtain the first access token.

[dustinmm80]

Is this summon-conjur behavior, or should the Docker image that holds summon/summon-conjur handle this?

[kgilpin]

We don't want to have to customize every Docker image that uses Summon to have to do this, which is why we want the provider to do it automatically.

[kgilpin]

In a K8s flow, the application container will be using Summon as the entrypoint. Summon can be provided to the application container by a volume link from the authentication sidecar. K8s doesn't provide a way to order the startup of the containers, so we want Summon to be smart enough to wait for the file $CONJUR_AUTHN_TOKEN_FILE to exist.

[dustinmm80]

Yeah but summon has nothing to do w/ conjur env vars. We're talking about summon-conjur right? I thought we could release an official summon-conjur Docker image with all this baked in, and people could use that.

[kgilpin]

"summon has nothing to do w/ conjur env vars."

Summon doesn't, but summon-conjur does. summon needs to be the entrypoint for the application container.

[kgilpin]

If I configure a container with CONJUR_APPLIANCE_URL, CONJUR_ACCOUNT, and CONJUR_AUTHN_TOKEN_FILE, and I make summon and summon-conjur available in that container, then I want to be able to use summon as the entrypoint, and I want summon-conjur to wait for CONJUR_AUTHN_TOKEN_FILE to exist.

summon and summon-conjur don't need to be part of the application image; they can be part of the authentication sidecar image, and provided to the application container via shared volume.

[dustinmm80]

Alright, that makes sense, thank you :)

[dustinmm80]

This was resolved in #13.