LEGO
- Canonical Telco
Channel | Revision | Published | Runs on |
---|---|---|---|
4/beta | 15 | 08 Oct 2024 | |
4/edge | 35 | Yesterday | |
4/edge | 34 | Yesterday |
juju deploy lego --channel 4/beta
Deploy universal operators easily with Juju, the Universal Operator Lifecycle Manager.
Platform:
Changes in configuration from the old DNS-plugin-specific LEGO charms
This charm is replacing the old Route53 LEGO K8s, Namecheap LEGO K8s, HTTPRequest LEGO K8s charms that have been in use for years. There are a couple of important changes with how this charm behaves over these charms that users will have to be aware of, but ultimately, a dynamic LEGO charm is more powerful and easier to configure than the previous charms we have.
We have moved over to using juju secrets to pass credentials to lego over using the configuration options directly. On top of the benefit of having your secrets protected, this change also allows users to pass in any config option to LEGO, even the ones that were previously unsupported.
For exaple, for route53, we supported the following configuration options:
email
server
This is actually a subset of all of the supported configuration options that LEGO provides. The full list is in the workload’s documentation located in go-acme.github.io. We are missing a critical option called AWS_SESSION_TOKEN
, which is required for all SSO or MFA enabled AWS accounts. This effectively means that if we do not add this option to our charm, it is not possible for users to utilize the charm using SSO or MFA enabled AWS accounts.
For the new LEGO charm, we’ve placed all of the plugin credential and configuration values into a secret so that you can pass any value you want to the workload.
This means you would add all of
aws_access_key_id
aws_hosted_zone_id
aws_max_retries
aws_polling_interval
aws_propagation_timeout
aws_region
aws_secret_access_key
aws_ttl
keys and their values to a juju secret, and LEGO will use optional paramaters if they are provided and logging errors if mandatory fields are missing.
For example, if you were configuring the httpreq-lego-operator as:
juju config \
server=<your ACME server> \
email=<your email address> \
httpreq_endpoint=<your HTTP Request endpoint> \
httpreq_http_timeout=<your optional value> \
httpreq_mode=<your optional value> \
httpreq_password=<your optional value> \
httpreq_polling_interval=<your optional value> \
httpreq_propagation_timeout=<your optional value> \
httpreq_username=<your optional value>
you would now move the plugin config options into a secret and provide its ID:
juju add-secret <your secret label> \
httpreq-endpoint=<your HTTP Request endpoint> \
httpreq-http_timeout=<your optional value> \
httpreq-mode=<your optional value> \
httpreq-username=<your optional value> \
httpreq-password=<your optional value> \
httpreq-polling_interval=<your optional value> \
httpreq-propagation_timeout=<your optional value>
juju grant-secret <your secret label> <lego charm name>
juju config \
server=<your ACME server> \
email=<your email address> \
plugin=httpreq \
plugin-config-secret-id=<the secret id juju printed when you added a secret>\
After providing the keys and values, the behavior of the new LEGO charm would be identical to the behavior of the old httpreq-lego-operator charm.