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

Feature: Take control of approval for the whole cluster #288

Open
SgtCoDFish opened this issue Oct 20, 2023 · 2 comments
Open

Feature: Take control of approval for the whole cluster #288

SgtCoDFish opened this issue Oct 20, 2023 · 2 comments

Comments

@SgtCoDFish
Copy link
Member

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)
@hawksight
Copy link
Member

hawksight commented Jan 22, 2024

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?

@SgtCoDFish
Copy link
Member Author

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!

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

No branches or pull requests

2 participants