Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Programmatically set ca.json configuration for containers #807

Open
smarsh-tim opened this issue Jan 24, 2022 · 1 comment
Open

Programmatically set ca.json configuration for containers #807

smarsh-tim opened this issue Jan 24, 2022 · 1 comment

Comments

@smarsh-tim
Copy link

What would you like to be added

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:

    function set_custom_vars () {
            if grep -Fq "maxTLSCertDuration" ${STEPPATH}/config/ca.json
            then
                echo "'maxTLSCertDuration' already set."
            else
                echo "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.
@smarsh-tim smarsh-tim added enhancement needs triage Waiting for discussion / prioritization by team labels Jan 24, 2022
@dopey
Copy link
Contributor

dopey commented Jan 27, 2022

Hey @smarsh-tim thanks for opening the issue!

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.

@dopey dopey added area/configuration and removed needs triage Waiting for discussion / prioritization by team labels Jan 27, 2022
maraino added a commit that referenced this issue Dec 15, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants