Allow users to define the expiration period for bootstrapper tokens

[lmbaschiera]

What would you like to be added

Allow users to define the expiration period for the tokens issued by the autocert pod and consumed by the autocert-bootstrapper initContainer.

Why this is needed

I'm working on a project that spawns multiple pods, all of which need to wait for another deployment to become available. This is achieved by adding an initContainer to them that polls to the API about the status of said deployment.
The issue I'm facing is that this deployment takes longer to become available than the expiration period set for the tokens issued by autocert, so by the time the autocert-bootstrapper initializes, the token has expired and has been automatically removed, making my pods wait for a condition that will never be met, hanging indefinitely until I manually restart the deployments.

[maraino]

Hi @lmbaschiera, adding a custom duration for the token would require a new way to generate the token. I want to add a package to make this easier in go.step.sm/crypto. But in the meantime, I can think of a simple solution and a more complex one:

The simplest one, which is the one I recommend, would be to use the annotation autocert.step.sm/init-first: "true", which will force the bootstrapper to run before any other initContainer. As long as the CA is available, you will get a certificate valid for 24h that should be enough for initializing the rest of the deployment. After the bootstrapper, it will run the rest of the initContainers that can wait for the dependencies to be ready.

Does this work for you?

---

I would stop reading, but in case you want a more complex but more customizable solution, ...

This requires creating your own bootstrapper image, here is the default one for reference, and use that one. In the helm chart would be adding custom values for these properties:

bootstrapper:
  image:
    repository: cr.step.sm/smallstep/autocert-bootstrapper
    pullPolicy: IfNotPresent
    tag: ""

This new bootstrapper image would need to create its own token and to be able to do that, you need to access at least the secret where the provisioner password is set. The easiest way to do this would be to add it to the container defined in the config.yaml. You can add a new volume with the secret.

Another challenge to address is being able to use multiple SANs. If you use only one, this one is available in the COMMON_NAME environment variable, but other SANs (autocert.step.sm/sans) are only available in the token, which can be accessed in the environment variable STEP_TOKEN, a way to access them would be to use something like this:

$ echo $STEP_TOKEN | step crypto jwt inspect --insecure | jq -r '.payload.sans | join(",")'
foo,bar,zar

Adding that to the environment STEP_SANS would allow you to create the token:

STEP_SANS=$(echo $STEP_TOKEN | step crypto jwt inspect --insecure  |  jq -r '.payload.sans | join(",")')
STEP_TOKEN=$(step ca token --not-after 10m --provisioner my-provisioner --provisioner-password-file /path/to/volume/secret.txt $COMMON_NAME)

And then continue with the rest of the bootstrap.sh.