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
policy: Add GetAuthTypes() #26116
policy: Add GetAuthTypes() #26116
Conversation
686db21
to
f7c3735
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thanks @jrajahalme
only the small non-blocking question regarding the API (first matching auth type vs bool)
Use PolicyCache in unit tests. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>
Track the required authentication mode for all selected remote identities in a selector policy, and add GetAuthType() that can be used to find out the required authentication mode between a local and remote security identity. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>
Track and return multiple AuthTypes for GetAuthTypes(), add multiple auth types to the distillery unit test. While we currently plan to only support Spire AuthType, the policy engine is wired for supporting multiple auth types. Honor this in the new GetAuthTypes() internal API. Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>
f7c3735
to
53a473b
Compare
Added commit to keep track and report multiple AuthTypes between a pair of local and remote IDs. |
/test Job 'Cilium-PR-K8s-1.26-kernel-net-next' hit: #25958 (91.70% similarity) |
I'm going to remove my review as the changes seem specific to auth policy, and the PR doesn't give any context for what was earlier broken, and whether there are now tests covering that logic. Hopefully we can lean on @mhofstetter's review. |
/test-1.26-net-next |
Added context to the PR description. PR contains changes to the policy package unit tests covering the new functionality. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, just some super minor nits on a couple of style/docs aspects. Feel free to roll into the PR, submit separately, or disagree with me in the threads below :)
l4Policy.AuthMap = make(AuthMap, 1) | ||
} | ||
authTypes := l4Policy.AuthMap[cs] | ||
if authTypes == nil { | ||
authTypes = make(AuthTypes, 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Why 1
? Presumably these should be sized based on the number of authentication rules for any particular endpoint (well, local endpoint identity) instead?
Background I'm thinking here is that maybe we are trying to set the default map size in order to micro-optimize for memory allocation, but we end up shooting ourselves in the foot because we force reallocations if there's more than one authenticated peer for the endpoint?
I guess overall you might argue that overall "number of unique peers an app connects to" amortizes towards one peer identity and hence selected by one rule 🤔.
A cursory search around Go default map capacity seems to suggest one bucket, eight entries... do we think there's a strong reason to be particular about this aspect here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking worst case we could end up recalculating new selectorPolicy on a regular basis, and every time we first allocate a map that's too small, then allocate again to a size that fits the policy. Mildly wasteful.
Anyway this is not a big deal, just seems like it may be premature optimization.
// GetAuthTypes returns the AuthTypes required by the policy between the localID and remoteID, if | ||
// any, otherwise returns nil. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: ID
can end up ambiguous, it'd be nice to give the reader one less thing to be confused about - stating clearly that the inputs are expected to be security identities. If by any weird course we end up plugging the wrong id numbers in, it could help point out the mistake.
// GetAuthTypes returns the AuthTypes required by the policy between the localID and remoteID, if | |
// any, otherwise returns nil. | |
// GetAuthTypes returns the AuthTypes required by the policy between the | |
// security identities localID and remoteID, if any, otherwise returns nil. |
CI is failing anyway so we can't merge this until that's resolved. |
Typically I'd expect |
One non-required test failing, mlh marked this as ready-to-merge. |
Track the required authentication mode for all selected remote identities
in a selector policy, and add GetAuthTypes() that can be used to find out
the required authentication modes between a local and remote security
identity.
We recently added authentication requirement support to Cilium Network Policy. This is currently plumbed to bpf datapath policymap values so that the datapath may enforce authentication status of traffic by consulting the new bpf authmap. Authmap is updated by Cilium Agent's auth manager (
pkg/auth
), currently based on the "authentication required" signals delivered from the datapath to the agent via signalmap. Once authentication is done, auth manager updates authmap and datapath starts accepting traffic.The new functionality provided in this PR is needed for the auth manager to be able to decide if an expiring authentication needs to be renewed (re-authenticated). Without this functionality re-authentication between given Cilium security IDs (local/remote) will be done perpetually, or until either the security ID is removed, or the node with which the authentication was done, is removed. The new
GetAuthTypes()
function is intended to be called by the auth manager to potentially end re-authentication for the given local/remote security ID pair, when no AuthTypes are returned, indicating that the policy has changed to not require authentication between the given local/remote security ID any more.#26068 uses this new functionality and is currently blocked for this functionality to be added.