Request: Implement access controls allowing a user to request certs for any subdomain of ${DOMAIN}

[jsimpso]

Enhancement Proposal

Hi,

I've run into some (at least to me) unexpected behaviour with this charm that I think we can improve for a better overall experience.

It's been established that if a user is allowed to request certs for example.com, this implicitly grants access to request a wildcard cert for *.example.com as the challenge domain is the same for either (see Canonical internal chat link).

What this doesn't do is allow that user to submit requests for any subdomain-specific certs, e.g. test.example.com.

Could we please look into either:

1. Leaning into this implicit access, authorising the user with access to example.com to request a cert for any valid domain matching ^.*\.example\.com$.
2. As we've established that granting access to *.example.com alongside example.com currently does nothing, change the behaviour so that granting access to *.example.com is a method of explicitly allowing the user to request a specific cert for any subdomain of example.com.
3. Adding some other method of explicitly allowing the user to request a certificate for any subdomain of example.com, such as juju run httprequest-lego-provider/0 allow-domains --string-args username=example-user domains='example.com' subdomains='example.com' or allow-subdomains --string-args username=example-user parent-domains='example.com'.

Keen to hear your thoughts.

Thanks!

[jsimpso]

After thinking on this some more I'm actually inclined to suggest that the implicit behavior of allowed-domains=example.com allowing a user to request the wildcard cert for *.example.com should be considered a bug in violation of the principle of least privilege, and should be replaced with a mechanism to explicitly grant access for requesting wildcard certs only where needed and justified.

[cbartz]

@arturo-seijas Can you have a look, please?

[arturo-seijas]

After thinking on this some more I'm actually inclined to suggest that the implicit behavior of allowed-domains=example.com allowing a user to request the wildcard cert for *.example.com should be considered a bug in violation of the principle of least privilege, and should be replaced with a mechanism to explicitly grant access for requesting wildcard certs only where needed and justified.

Hi @jsimpso, what is that you have in mind and how would it look like from a user's perspective?

[amandahla]

@jsimpso friendly ping

[jsimpso]

Apologies for the delayed response.

After thinking on this some more I'm actually inclined to suggest that the implicit behavior of allowed-domains=example.com allowing a user to request the wildcard cert for *.example.com should be considered a bug in violation of the principle of least privilege, and should be replaced with a mechanism to explicitly grant access for requesting wildcard certs only where needed and justified.

Hi @jsimpso, what is that you have in mind and how would it look like from a user's perspective?

On the topic of wildcard certificates, I think that if we grant access to example-user to request certificates for example.com:

juju run httprequest-lego-provider/0 allow-domains --string-args username=example-user domains='example.com'

The permission granted should be limited what is explicitly stated: example-user should be allowed to request a certificate for "example.com".

If we want to allow that user to request requests for wildcard certificates, that should be an explicit action. From the perspective of the administrator making that access request, I could see this working one of two ways:

1. Requiring the string "*.example.com" to be allowed in order to generate a wildcard certificate for *.example.com

juju run httprequest-lego-provider/0 allow-domains --string-args username=example-user domains='*.example.com'

1. Requiring a separate argument altogether to control access to generate wildcard certificates:

juju run httprequest-lego-provider/0 allow-domains --string-args username=example-user wildcard_domains='example.com'

---

On the topic of subdomains, I think it would be useful to have an access control option allowing users to request any specific subdomain of a given domain rather than using a wildcard certificate. For example:

1. Allowing example-user to request certificates for any specific subdomain of example.com, but not a wildcard certificate, and not a certificate for *.example.com itself.

juju run httprequest-lego-provider/0 allow-domains --string-args username=example-user subdomains='example.com'

1. Allowing example-user to request certificates for example.com, any specific subdomain of example.com, but not a wildcard certificate for *.example.com:

juju run httprequest-lego-provider/0 allow-domains --string-args username=example-user domains='example.com' subdomains='example.com'

---

Hopefully that makes sense, please let me know if not! Thanks :)

[arturo-seijas]

@gregory-schiano , what do you think?

[alithethird]

@arturo-seijas is this still relevant?

[arturo-seijas]

@gregory-schiano ?

[gregory-schiano]

Sorry, I remembered that we already discussed this kind of things and wanted to dig to retrieve the discussions.
So we indeed something similar like supporting regular expressions in the ACL allowing more flexibility and getting more specific for the meaning of "*.example.com"
The decision back in the days has been to only work on this if there were a feature request, and there we are.

So I think this is definitely something we could work on, I can't guarantee we'll apply exactly the solution proposed by James, but we'll definitely take the input.
We now need to see if we can squeeze this feature request in this cycle, or add it to our roadmap for next cycle.

[jsimpso]

I believe this will lead to a significant improvement for user experience in the ingress model we're currently implementing for machine workloads.

In this ingress model, an infrastructure team deploys an HAProxy cluster and offers remote integration for customer workloads via the haproxy-route endpoint.

Lego is deployed alongside HAProxy and configured to use the httpreq plugin to talk to httprequest-lego-provider.

We want to be able to configure the ACLs here to say "allow this httpreq user to request a certificate for any subdomain of 'example.canonical.com'", so that customers can integrate with the offered HAProxy for a site at 'test.example.canonical.com' without gating on manual approval for each individual subdomain.

Happy to discuss further, just let me know

[swetha1654]

Hi @jsimpso , the PR to provide subdomain support has been merged and this feature should now be available from rev 57 onwards.

With respect to support for wildcard domains, i had initially proposed httprequest-lego-provider supporting "RAW" mode for the challenge APIs. But upon further investigation, i found out that the wildcard (*) is stripped from the domain even in the RAW mode before calling the /present and /cleanup APIs. I reached out to the upstream lego client raising this issue and they mentioned that it is not useful for the DNS challenge providers to have that piece of information and they currently cannot support providing wildcard in the raw domain.

The reason it seems to be a problem for us is because of our current architecture. The access control (allowing/revoking access for users to domains) is validated AFTER httprequest-lego-provider receives the challenge APIs. Ideally, the ACL layer needs to be between the certificate requirer charm and the lego charm, so that the ACL layer can first validate if the user credentials have respective permissions and then forward the request to LEGO.

But this has its own problems as well, as with the new proposed solution, IS would have to take control over the lego charm and is not managed by the end users anymore.

Since we are currently not planning to support this, the wildcard issue will remain an open problem.

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/ISD-4048.

This message was autogenerated