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.

Sign up for GitHub

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

Jump to bottom

policy: Adjust existing policy for visibility annotations #16258

Merged
merged 4 commits into from
Sep 2, 2021
Merged

policy: Adjust existing policy for visibility annotations #16258

merged 4 commits into from
Sep 2, 2021

Commits on Aug 19, 2021

  1. policy: Generalize MapState owners 

    Allow other types in addition to CachedSelectors to own MapState
entries. This is needed to properly track entires added due to deny
rules so that incremental map updates can be performed correctly.

Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>
    @jrajahalme
    jrajahalme committed Aug 19, 2021
    Configuration menu
    Copy the full SHA
    3cd83b7 View commit details
    Browse the repository at this point in the history

  2. policy: Do not expose internal maps to callers 

    MapState internal state could be modified by callers via internal
maps. Nil them on entries stored outside of the MapState itself.

Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>
    @jrajahalme
    jrajahalme committed Aug 19, 2021
    Configuration menu
    Copy the full SHA
    ae2d6ee View commit details
    Browse the repository at this point in the history

  3. policy: Keep track of dependent (deny) entries 

    MapState entries that should be deleted together with some other
entry are "dependent entries". These are created for some deny
entries. Keep track of them, and delete them when the main entry is
deleted.

Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>
    @jrajahalme
    jrajahalme committed Aug 19, 2021
    Configuration menu
    Copy the full SHA
    7079b2b View commit details
    Browse the repository at this point in the history

  4. policy: Adjust existing policy for visibility annotations 

    Adjust and expand eBPF policy map to redirect for visibility on the
port of the visibility annotation while still denying traffic on this
port for identities for which the traffic is denied.

Datapath lookup order is, from highest to lowest precedence:
1. L3/L4
2. L4-only (wildcard L3)
3. L3-only (wildcard L4)
4. Allow-all

This means that the L4-only allow visibility key can only be added if
there is an allow-all key, and all L3-only deny keys are expanded to
L3/L4 keys. If no L4-only key is added then also the L3-only allow
keys need to be expanded to L3/L4 keys for visibility redirection. In
addition the existing L3/L4 and L4-only allow keys need to be
redirected to the proxy port, if not already redirected.

The above can be accomplished by:

1. Change existing L4-only ALLOW key on matching port that does not already
   redirect to redirect.
   - e.g., 0:80=allow,0 -> 0:80=allow,<proxyport>
2. If allow-all key exists, add L4-only visibility redirect key if the L4-only
   key does not already exist.
   - e.g., 0:0=allow,0 -> add 0:80=allow,<proxyport> if 0:80 key does not exist
     - this allows all traffic on port 80, but see step 5 below
3. Change all L3/L4 ALLOW keys on matching port that do not already redirect to
   redirect.
   - e.g, <ID1>:80=allow,0 -> <ID1>:80=allow,<proxyport>
4. For each L3-only ALLOW key add the corresponding L3/L4 ALLOW redirect if no
   L3/L4 key already exists and no L4-only key already exists and one is not added.
   - e.g., <ID2>:0=allow,0 -> add <ID2>:80=allow,<proxyport> if <ID2>:80
     and 0:80 do not exist and 0:80 was not added
5. If a new L4-only key was added: For each L3-only DENY key add the
   corresponding L3/L4 DENY key if no L3/L4 key already exists
   - e.g., <ID3>:0=deny,0 -> add <ID3>:80=deny,0 if <ID3>:80 does not exist

With the above we only change/expand existing allow keys to redirect, and
expand existing drop keys to also drop on the port of interest, if a new
L4-only key allowing the port is added.

Adjust the unit test to mimic the real behavior a bit better by
regenerating endpoint policy after updating visibility policy. This is
needed due to the test using same port for HTTP and Kafka, and without
regenerating visibility redirects no longer overwrite existing
redirects.

Visibility redirects need to be re-applied after applying incremental
policy map changes. This is due to incremental changes possibly adding
keys for new identities that need visibility redirections or
additional deny keys as defined above.

Testing: New unit tests in policy package cover all the cases
described above.

Signed-off-by: Jarno Rajahalme <jarno@isovalent.com>
    @jrajahalme
    jrajahalme committed Aug 19, 2021
    Configuration menu
    Copy the full SHA
    0afc0c0 View commit details
    Browse the repository at this point in the history