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.

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

add except to ipBlock #6428

Closed
jsalatiel opened this issue Jun 11, 2024 · 3 comments · Fixed by #6658
Closed

add except to ipBlock #6428

jsalatiel opened this issue Jun 11, 2024 · 3 comments · Fixed by #6658
Assignees
Labels
area/network-policy/api Issues or PRs related to the network policy API. kind/feature Categorizes issue or PR as related to a new feature.

Comments

@jsalatiel
Copy link

jsalatiel commented Jun 11, 2024

Hi everyone, I understand that the "except" is not part of the IPBlock in antrea per

IPBlock field in the ClusterNetworkPolicy rules do not have the except field. A higher priority rule can be written to deny the specific CIDR range to simulate the behavior of IPBlock field with cidr and except set.

It would be a nice feature to add that. Create a higher priority rule is not always a feasible or looks clean for those debugging problems.

Let's take this example:

Premise:

  1. Native KNP creation is blocked. ( We want to avoid the isolation created by KNPs and keep the more intuitive firewall behaviour provided by ANP)
  2. Developers can create ANP only in Application Tier.
  3. Cluster Operators create ACNP to secure the cluster in SecurityOps and NetworkOps tier.
  4. There is one single ACNP in Baseline tier that does deny all.

Now let's say that we want a easy way to provide internet for pods. By internet I mean ports 80 and 443 to:
something like:

ipBlock: 0.0.0.0
except:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16

With that pods can go to outside, but won't have access to private ips on port 80 and 443.

To implement that, currently I need to do something like:

apiVersion: crd.antrea.io/v1beta1
kind: ClusterNetworkPolicy
metadata:
  name: allow-internet-by-label
spec:
    appliedTo:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          internet: 'true'
    egress:
      - action: Pass
        to:
        - ipBlock:
            cidr: 10.0.0.0/8
        - ipBlock:
            cidr: 172.16.0.0/12
        - ipBlock:
            cidr: 192.168.0.0/16
        ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443
      - action: Allow
        to:
        - ipBlock:
            cidr: 0.0.0.0/0
        ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443

If I add that in the SecurityOps or NetworkOps, that "Pass" will effectively block the developers from letting the pods talk to the internet and also access any other internal service on port 80/443 by creating ANP in application tier. The only way that can somehow work is to create that Cluster policy as the lowest priority possible in Application Tier. But again, that looks more like a NetworkOps "rule" than a Application rule.

If we could have except in IPBlock, that rule could be easily created as:

apiVersion: crd.antrea.io/v1beta1
kind: ClusterNetworkPolicy
metadata:
  name: allow-internet-by-label
spec:
  priority: 1
  tier: NetworkOps
  appliedTo:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        internet: 'true'
  egress:
    - action: Allow
      to:
      - ipBlock:
          cidr: 0.0.0.0/0
          except:
          - 10.0.0.0/8
          - 172.16.0.0/12
          - 192.168.0.0/16
      ports:
      - protocol: TCP
        port: 80
      - protocol: TCP
        port: 443

and that rule would interfere with no other rule and it would be "self-contained".

Somehow related:
#6424

@jsalatiel jsalatiel added the kind/feature Categorizes issue or PR as related to a new feature. label Jun 11, 2024
@antoninbas
Copy link
Contributor

@jsalatiel we discussed this at our community meeting this week, and the consensus was that it would be good to add this feature to the Antrea native policy API. See https://github.com/antrea-io/antrea/wiki/Community-Meetings#june-17-2024.

@antoninbas antoninbas added the area/network-policy/api Issues or PRs related to the network policy API. label Jun 18, 2024
@antoninbas
Copy link
Contributor

@Dyanngg I am assigning the issue to you, but feel free to re-assign if needed

@jsalatiel
Copy link
Author

@jsalatiel we discussed this at our community meeting this week, and the consensus was that it would be good to add this feature to the Antrea native policy API. See https://github.com/antrea-io/antrea/wiki/Community-Meetings#june-17-2024.

That's amazing!

@antoninbas antoninbas added this to the Antrea v2.2 release milestone Jul 26, 2024
antoninbas pushed a commit that referenced this issue Oct 9, 2024
Fixes #6428

This PR adds an "except" field for all ipBlocks in Antrea-native
policies and groups. Users can exclude certain CIDRs from the
ipBlock.cidr in all resources that support ipBlocks, including
AntreaClusterNetworkPolicy, AntreaNetworkPolicy, ClusterGroup and
Group. Group membership and IP association query logic are also updated
to accommodate this change. Documentation will follow in a separate PR.

Signed-off-by: Dyanngg <dingyang@vmware.com>
hangyan pushed a commit to hangyan/antrea that referenced this issue Oct 29, 2024
Fixes antrea-io#6428

This PR adds an "except" field for all ipBlocks in Antrea-native
policies and groups. Users can exclude certain CIDRs from the
ipBlock.cidr in all resources that support ipBlocks, including
AntreaClusterNetworkPolicy, AntreaNetworkPolicy, ClusterGroup and
Group. Group membership and IP association query logic are also updated
to accommodate this change. Documentation will follow in a separate PR.

Signed-off-by: Dyanngg <dingyang@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/network-policy/api Issues or PRs related to the network policy API. kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants