You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, approver-policy can't explicitly deny any certs by default because it has to account for the possibility that there's another approver working in the cluster which might make an approval decision for that CR.
As a user who doesn't intend to ever install a separate approver, though, that might not be ideal - I'd maybe rather have approver-policy explicitly deny everything with a message like "CertificateRequest is denied because no CertificateRequestPolicy matched it" or "CertificateRequest is denied because it wasn't approved by any matching CertificateRequestPolicy resource".
Essentially, it would allow us to help users debug policy more accurately.
Open problems with this idea:
We probably can't default to it because it might be breaking in the case where another approver is already installed
In the case that another approver is installed, we will currently race with that other approver (which is why we don't deny-all in the first place)
This might not ever be solvable without some other mechanism such as a leader election for approval (or moving approval into core cert-manager, which I don't think is on the table)
The text was updated successfully, but these errors were encountered:
We probably can't default to it because it might be breaking in the case where another approver is already installed
Is it possible to do something like leader election but for approval things? I am thinking that if it is difficult to know if another approver is enabled, can we find a way to make it easier, but dropping some reference somewhere in k8s that can be checked by other approval installs?
I think it's possible to do some sort of leader election sure!
One possibility is that since we know there'll be a cert-manager instance in the cluster and we know there'll be one, we could have cert-manager hand out a lease for something to claim and allow cert-manager to handle that. It'd allow for things like having a different approver per-namespace.
We could also potentially use Kubernetes' inbuilt support for this. There are options!
Today, approver-policy can't explicitly deny any certs by default because it has to account for the possibility that there's another approver working in the cluster which might make an approval decision for that CR.
As a user who doesn't intend to ever install a separate approver, though, that might not be ideal - I'd maybe rather have approver-policy explicitly deny everything with a message like "CertificateRequest is denied because no CertificateRequestPolicy matched it" or "CertificateRequest is denied because it wasn't approved by any matching CertificateRequestPolicy resource".
Essentially, it would allow us to help users debug policy more accurately.
Open problems with this idea:
The text was updated successfully, but these errors were encountered: