Order of reconcilliation of the AuthConfigs should not matter to rebuild the cache
guicassolato opened this issue · comments
The outcome state of the reconcilliation of AuthConfigs containing host overlaps is subject to the order that the CRs are processed by Authorino and added to the cache.
The behaviour depends on the reconcilliation mode set for the Authorino instance, either namespaced or cluster-wide.
What's the difference?
- Cluster-wide: Authorino refuses to override the currently cached auth rules when the host name is already taken and the two AuthConfigs involved (i.e. the one cached and the new incoming one) are from different k8s namespaces.
- Namespaced: the AuthConfig that comes after always overrides what's in the cache.
Nonetheless, effectively in both cases the order that the AuthConfigs are reconciled matters, potentially leading to inconsistent states of the cache for overlapping host names after a pod occasionally restarts.
Example
Given:
- AuthConfig A specifies a set of auth rules a for a host name h;
- AuthConfig B specifies a set of auth rules b for also host name h.
If A is reconciled and then comes B,
- In cluster-wide mode:
- Authorino rejects B because h is 'already taken' (linked to A) and therefore a will be enforced.
- In namespaced mode:
- Authorino accepts B overriding a with b which thereafter will be enforced to protect h.
(And vice-versa if the order is instead first B, then A.)
If the Authorino pod restarts, the order that the CRs will be reconciled cannot be guaranteed and therefore the state of the cache can end up different than the one before restarting.
The table below summarises for all the cases:
| Reconcilliation mode | Pod running at t | Pod running at t+1 after restart | # | ||
|---|---|---|---|---|---|
| Order | State of the cache for h (t) | Order | State of the cache for h (t+1) | ||
| Cluster-wide | A → B | a | A → B | a | 1 |
| A → B | a | B → A | b | 2 | |
| B → A | b | B → A | b | 3 | |
| B → A | b | A → B | a | 4 | |
| Namespaced | A → B | b | A → B | b | 5 |
| A → B | b | B → A | a | 6 | |
| B → A | a | B → A | a | 7 | |
| B → A | a | A → B | b | 8 | |
Obviously cases 2, 4, 6 and 8, where state of the cache at t+1 is not the same as at t, are not desirable.
Ideally, Authorino would repopulate the cache after a pod restarts in a way such that the same state is guaranteed before and after the restart, regardless of the order that the AuthConfigs are reconciled – possibly by concurrent threads.