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

enable cert auth for default admin #66

Open
qrkourier opened this issue Mar 7, 2023 · 5 comments
Open

enable cert auth for default admin #66

qrkourier opened this issue Mar 7, 2023 · 5 comments
Labels
good first issue Good for newcomers

Comments

@qrkourier
Copy link
Member

https://openziti.discourse.group/t/admin-life-cycle-from-password-to-long-lived-cert/1127/7?u=qrkourier

@qrkourier qrkourier added the good first issue Good for newcomers label Oct 5, 2023
@qrkourier
Copy link
Member Author

Now that the ziti CLI supports certificate authentication, setting the default admin user's password as an environment variable is no longer necessary. This will improve the security posture of the controller container by reducing exposure of that vital secret.

  1. Change the ziti-controller helm chart to mount the Certificate resource {{ include "ziti-controller.fullname" . }}-admin-client-cert's tls.crt and tls.key on the controller container. This client certificate from Ziti Edge CA is managed by cert-manager and is created when the controller chart is installed.
  2. Change the zitiLogin script to use the client cert auth feature of ziti CLI

@kevinlmadison
Copy link
Contributor

This looks like it may be completed.

@qrkourier
Copy link
Member Author

I did add the admin client cert via cert manager, but didn't change the login command to use it.

It may be necessary to create an authenticator, which will be simpler to achieve when this feature is completed: openziti/ziti#1730

https://github.com/search?q=repo%3Aopenziti%2Fhelm-charts%20admin-client-cert&type=code

@qrkourier
Copy link
Member Author

An alternative to issuing the admin client cert with cert manager would be to add an init step for the controller. It would use the CLI to create a second admin w/ cert authenticator, enroll, unwrap the JSON to the crypto components the CLI currently requires, and then stuff them into a K8s TLS Secret resource to be mounted later by Job containers that need to do admin stuff. This would give the cluster/ziti admin the option to subsequently delete the username/password Secret from the cluster, thereby reducing exposure and safekeeping elsewhere as a backup auth method.

@qrkourier
Copy link
Member Author

Now that I think about that idea above, however, it's probably simpler to keep the client cert issued by cert manager and just use the new init or life-cycle Job to create an authenticator for the first/default admin for that cert's fingerprint. Same security posture in the end, but fewer steps.

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

No branches or pull requests

2 participants