You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to be able to programmatically set ca.json configuration settings, such as maxTLSCertDuration via the step ca init script. Support for a DOCKER_ environment variable would be ideal, much like how values like DOCKER_STEPCA_INIT_NAME are being passed.
Why this is needed
This will allow me to configure additional fields that aren't currently supported during step ca init. A specific example is maxTLSCertDuration, which defaults to 24 hours. I would like to increase this settings to a greater value.
Editing the ca.json manually and restarting is not preferred in a container orchestrated setup.
So we're left to doing something a little hacky like this in the entrypoint.sh script for the Dockerfile:
functionset_custom_vars () {
if grep -Fq "maxTLSCertDuration"${STEPPATH}/config/ca.json
thenecho"'maxTLSCertDuration' already set."elseecho"Did not find 'maxTLSCertDuration' in ca.json. Adding value before start."
mkdir -p ${STEPPATH}/config/backups
cp ${STEPPATH}/config/ca.json ${STEPPATH}/config/backups/ca.json_$(date +%s)
awk 'NR==1{print; print " \"maxTLSCertDuration\":\"48\","} NR!=1'${STEPPATH}/config/ca.json > /tmp/ca.json && mv /tmp/ca.json ${STEPPATH}/config/ca.json
fi
}
Note that jq isn't available on the Alpine image, and an init container wouldn't do much since the step ca init occurs first, then we make the changes, then start up.
The text was updated successfully, but these errors were encountered:
This is definitely a problem. Unfortunately we're not quite sure what the answer should be, and we don't want to implement something half-baked. We've been discussing for a while having some sort of import / export functionality for CA config - this issue might get rolled into that.
Our short term suggested fix is to generate your ca.json separately and then mount it as a volume. There's code in the entrypoint.sh file to bypass step ca init if a config file is already in the right location. Let us know if you're having trouble getting that working.
This commit will ignore principals validation when an OIDC provisioner
is used. When the principals in the server does not match the principals
given the validation was failing, even if the proper principals were set
by templates or webhooks. With this change OIDC will not validate the
principals and just set the default ones (name, [email protected]) plus
the ones in the templates.
This commit also includes a change in the templates to allow to pass
a provisioner to the $(step path)/ssh/config template
Related to #807
What would you like to be added
I would like to be able to programmatically set ca.json configuration settings, such as
maxTLSCertDuration
via thestep ca init
script. Support for a DOCKER_ environment variable would be ideal, much like how values likeDOCKER_STEPCA_INIT_NAME
are being passed.Why this is needed
This will allow me to configure additional fields that aren't currently supported during
step ca init
. A specific example ismaxTLSCertDuration
, which defaults to 24 hours. I would like to increase this settings to a greater value.Editing the ca.json manually and restarting is not preferred in a container orchestrated setup.
So we're left to doing something a little hacky like this in the entrypoint.sh script for the Dockerfile:
jq
isn't available on the Alpine image, and an init container wouldn't do much since the step ca init occurs first, then we make the changes, then start up.The text was updated successfully, but these errors were encountered: