Skip to content

Commit

Permalink
small integrations
Browse files Browse the repository at this point in the history
Signed-off-by: Flavio Castelli <[email protected]>
  • Loading branch information
flavio committed Aug 11, 2023
1 parent 307e72e commit 8fe24d0
Showing 1 changed file with 32 additions and 1 deletion.
33 changes: 32 additions & 1 deletion rfc/0018-certificate-handling.md
Original file line number Diff line number Diff line change
Expand Up @@ -103,7 +103,7 @@ flowchart TD
A -->D(Policy Server #2)
```

## Reconciliation Loops
## Possible Scenarios

This section aims to cover the different scenarios. For each one of them we start by defining an event
and then outline the different actions that have to be done.
Expand Down Expand Up @@ -167,6 +167,37 @@ Once the new CA is generated, the following actions have to be performed:
This change is massive and could lead to connection errors for as long as the PolicyServer are using a certificate
signed by a CA that is not the one mentioned inside of the `clientConfig.caBundle`.

## Reconciliation Loops

This section describes how the kubewarden-controller reconciliation loops should be arranged.

Currently we have these reconciliation loops:

- `PolicyServer`
- `ClusterAdmissionPolicy`
- `AdmissionPolicy`

### Policy Server

Reconciliation loops are triggered whenever an event dealing with a watched resource happens.
In this case it could be the create/update/delete of a `PolicyServer`.
The reconciliation loop is also triggered every X seconds as a way to cope with possible glitches
with the event notification system.

At the beginning of the reconciliation loop, the code should check the expiration date of the
certificate used by the Policy Server. If the certificate is about to expire a new one should be
created. Check the previous section to see which actions have to be done in this circumstance.

The loop should also monitor changes done to the secret that holds the internal CA.
The reconciliation loop should then make sure that the Policy Server certificate has been signed by
our CA. If not, a new certificate should be issued (like during a renewal).

> Note: checking if the Policy Server certificate has been issued by our CA might be computationally intense.
> We have to ensure this is not going to cause a CPU spike. We could resort to do something clever using
> the revision number of the Secret that holds the CA.

TODO: write about the other loops

# Drawbacks

[drawbacks]: #drawbacks
Expand Down

0 comments on commit 8fe24d0

Please sign in to comment.