Skip to content

all: implement fetching additional domains from setec secret #12

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

twitchyliquid64
Copy link

This implements fetching additional domains to maintain certs for from a setec secret, which is refreshed periodically.

This eliminates the need to bounce scertecd when domains change, unless they were provided as a command-line parameter.

Invocations of scertecd can now specify the setec secret using --additional-domains-key.

This implements fetching additional domains to maintain certs for from a setec secret, which is refreshed periodically.

This eliminates the need to bounce scertecd when domains change, unless they were provided as a command-line parameter.

Invocations of scertecd can now specify the setec secret using `--additional-domains-key`.

Signed-off-by: Tom DNetto <[email protected]>
Copy link
Member

@creachadair creachadair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bradfitz
Copy link
Member

bradfitz commented Mar 13, 2024

I thought about it more and I still don't like this. I don't see what problem it solves.

Also, a move this big (moving to use setec for configuration management) should have an issue with a plan. Like: we scale up some count of some server type in prod configuration files and then we terraform+ansible+ ... something else now to write the setec secret with configuration? Or does some terraform/ansible step do that? Which? Do we then have to wait for that config to be rolled out everywhere? Or are we depending on certd only running one copy for now?

Whereas if we just don't do this, we instead just modify the config files and re-deploy and it restarts the binary with the new flags.

@twitchyliquid64
Copy link
Author

The problem it solves is having to manually adjust command lines or files on a box and bounce certd whenever we want to add a new trunk. The plan was to make the secret accessible to humans only and add a step to add the new trunk name to the secret as part of bringup instructions.

I believe multiple certd's will cause the same problems (duplicate issuance when racing) with or without this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants