Skip to content

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

@SgtCoDFish

Description

@SgtCoDFish

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)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions