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

AppliedTo Per Rule for Antrea-native Policies #1396

Merged
merged 5 commits into from
Dec 17, 2020

Conversation

Dyanngg
Copy link
Contributor

@Dyanngg Dyanngg commented Oct 16, 2020

This PR fixes #1327. Please refer to the issue for more information on this feature.

The following changes are made in terms of implementation:

  • Add admission webhook validation to ensure that the appliedTo is set at either spec level or rule level, but not both.
  • Add a AppliedToPerRule field in multiple policy rule structs to indicate which level appliedTo was set.
  • For the internalNP, AppliedToGroups are set as spec.appliedTo or the union of all rule.appliedTo. The original span calculations and stale appliedToGroup cleanups would seamlessly work.
  • In agent, use the AppliedToPerRule flag to determine appliedTo for each PolicyRule.

@antrea-bot
Copy link
Collaborator

Thanks for your PR.
Unit tests and code linters are run automatically every time the PR is updated.
E2e, conformance and network policy tests can only be triggered by a member of the vmware-tanzu organization. Regular contributors to the project should join the org.

The following commands are available:

  • /test-e2e: to trigger e2e tests.
  • /skip-e2e: to skip e2e tests.
  • /test-conformance: to trigger conformance tests.
  • /skip-conformance: to skip conformance tests.
  • /test-whole-conformance: to trigger all conformance tests on linux.
  • /skip-whole-conformance: to skip all conformance tests on linux.
  • /test-networkpolicy: to trigger networkpolicy tests.
  • /skip-networkpolicy: to skip networkpolicy tests.
  • /test-windows-conformance: to trigger windows conformance tests.
  • /skip-windows-conformance: to skip windows conformance tests.
  • /test-windows-networkpolicy: to trigger windows networkpolicy tests.
  • /skip-windows-networkpolicy: to skip windows networkpolicy tests.
  • /test-hw-offload: to trigger ovs hardware offload test.
  • /skip-hw-offload: to skip ovs hardware offload test.
  • /test-all: to trigger all tests (except whole conformance).
  • /skip-all: to skip all tests (except whole conformance).

@codecov-io
Copy link

codecov-io commented Oct 16, 2020

Codecov Report

Merging #1396 (c85e45e) into master (9d3d10b) will decrease coverage by 0.79%.
The diff coverage is 60.67%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1396      +/-   ##
==========================================
- Coverage   63.31%   62.52%   -0.80%     
==========================================
  Files         170      181      +11     
  Lines       14250    15499    +1249     
==========================================
+ Hits         9023     9691     +668     
- Misses       4292     4786     +494     
- Partials      935     1022      +87     
Flag Coverage Δ
e2e-tests 25.88% <21.37%> (?)
kind-e2e-tests 53.00% <54.37%> (-2.38%) ⬇️
unit-tests 40.66% <29.51%> (-0.62%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
cmd/antrea-agent/agent.go 0.00% <0.00%> (ø)
.../agent/apiserver/handlers/networkpolicy/handler.go 58.33% <ø> (ø)
...gent/controller/noderoute/node_route_controller.go 45.83% <0.00%> (-0.64%) ⬇️
pkg/agent/stats/collector.go 97.72% <ø> (ø)
pkg/antctl/antctl.go 100.00% <ø> (ø)
pkg/antctl/transform/controllerinfo/transform.go 0.00% <ø> (ø)
pkg/antctl/transform/version/transform.go 44.82% <ø> (ø)
pkg/controller/networkpolicy/tier.go 90.00% <ø> (ø)
pkg/controller/types/networkpolicy.go 100.00% <ø> (ø)
pkg/features/antrea_features.go 16.66% <ø> (ø)
... and 87 more

@Dyanngg
Copy link
Contributor Author

Dyanngg commented Oct 29, 2020

/test-all

@antrea-bot
Copy link
Collaborator

Thanks for your PR.
Unit tests and code linters are run automatically every time the PR is updated.
E2e, conformance and network policy tests can only be triggered by a member of the vmware-tanzu organization. Regular contributors to the project should join the org.

The following commands are available:

  • /test-e2e: to trigger e2e tests.
  • /skip-e2e: to skip e2e tests.
  • /test-conformance: to trigger conformance tests.
  • /skip-conformance: to skip conformance tests.
  • /test-all-features-conformance: to trigger conformance tests with all alpha features enabled.
  • /skip-all-features-conformance: to skip conformance tests with all alpha features enabled.
  • /test-whole-conformance: to trigger all conformance tests on linux.
  • /skip-whole-conformance: to skip all conformance tests on linux.
  • /test-networkpolicy: to trigger networkpolicy tests.
  • /skip-networkpolicy: to skip networkpolicy tests.
  • /test-windows-conformance: to trigger windows conformance tests.
  • /skip-windows-conformance: to skip windows conformance tests.
  • /test-windows-networkpolicy: to trigger windows networkpolicy tests.
  • /skip-windows-networkpolicy: to skip windows networkpolicy tests.
  • /test-hw-offload: to trigger ovs hardware offload test.
  • /skip-hw-offload: to skip ovs hardware offload test.
  • /test-all: to trigger all tests (except whole conformance).
  • /skip-all: to skip all tests (except whole conformance).

@Dyanngg Dyanngg force-pushed the applied-to-per-rule branch 4 times, most recently from f09ae26 to 349e3b2 Compare December 8, 2020 23:57
@Dyanngg
Copy link
Contributor Author

Dyanngg commented Dec 9, 2020

/test-all

Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some comments, but I am not the best person to review NP changes in the controller & agent

pkg/agent/controller/networkpolicy/cache_test.go Outdated Show resolved Hide resolved
pkg/apis/controlplane/types.go Outdated Show resolved Hide resolved
pkg/apis/controlplane/v1beta1/conversion.go Outdated Show resolved Hide resolved
pkg/controller/networkpolicy/validate.go Outdated Show resolved Hide resolved
test/e2e/antreapolicy_test.go Outdated Show resolved Hide resolved
Comment on lines +33 to +34
PodSelectorMatchExp *[]metav1.LabelSelectorRequirement
NSSelectorMatchExp *[]metav1.LabelSelectorRequirement
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really introduced by this PR, but I don't recall why these have to be pointers, while PodSelector / NSSelector do not. Do you know the reason?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure... Maybe because Maps are already passed by reference?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that may make sense for function parameters (except if we never mutate the slice), but not really for fields in a struct

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe you can punt this to the later commit you mentioned in https://github.com/vmware-tanzu/antrea/pull/1396/files#r539671256

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened #1647 for this

test/e2e/utils/anpspecbuilder.go Show resolved Hide resolved
@Dyanngg Dyanngg force-pushed the applied-to-per-rule branch 2 times, most recently from 369a403 to b41f200 Compare December 10, 2020 05:35
@Dyanngg
Copy link
Contributor Author

Dyanngg commented Dec 10, 2020

/test-all

Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall

pkg/controller/networkpolicy/validate.go Outdated Show resolved Hide resolved
pkg/controller/networkpolicy/validate.go Outdated Show resolved Hide resolved
pkg/agent/controller/networkpolicy/cache.go Outdated Show resolved Hide resolved
@Dyanngg Dyanngg force-pushed the applied-to-per-rule branch 2 times, most recently from 8dfc7ed to 72032c3 Compare December 10, 2020 19:07
@Dyanngg
Copy link
Contributor Author

Dyanngg commented Dec 10, 2020

/test-all

}
numAppliedToInRules := countAppliedToInRules(ingress) + countAppliedToInRules(egress)
if appliedToInSpec && (numAppliedToInRules > 0) {
return "appliedTo should not be set in both spec and rules", false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I must have missed some discussions. But why appliedTo cannot be on both rules and NP?
@abhiraut

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we decided to keep the implementation simple and not support a hybrid AppliedTo .. initially i thought we could inherit the appliedTo from the spec in to the rule if no AppliedTo set on the rule.. i am not sure if the implementation becomes too complex to support a hybrid setup?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spoke offline, at this moment we will keep the current implementation and disallow the hybrid case

Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but please get an approval from @abhiraut or @tnqn as well.

@@ -111,7 +111,9 @@ func ToNetworkPolicyMsg(in *types.NetworkPolicy, out *controlplane.NetworkPolicy
}
// Since stored objects are immutable, we just reference the fields here.
out.Rules = in.Rules
out.AppliedToGroups = in.AppliedToGroups
if !in.AppliedToPerRule {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe add a small comment for this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@Dyanngg
Copy link
Contributor Author

Dyanngg commented Dec 14, 2020

/test-all

// Select workloads on which this rule will be applied to. Cannot be set in
// conjunction with NetworkPolicySpec/ClusterNetworkPolicySpec.AppliedTo.
// +optional
AppliedTo []NetworkPolicyPeer `json:"appliedTo,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not suggesting any change for now. But want to mention I would consider to define a separate struct for AppliedTo instead of using NetworkPolicyPeer, that can be shared by different types of policies, and can remove the requirements of validating unsupported fields of NetworkPolicyPeer.
Check my idea here: https://github.com/vmware-tanzu/antrea/pull/1433/files#diff-820e873e5691a9f56ffc35887e7e006745a9ff4b0c547b994687f06a9db3919fR79. @abhiraut

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working on integrating the ClusterGroup with ACNP/ANP. the struct you are proposing is similar to a Group/ClusterGroup.. do you want to reuse the same CRD for snat policy?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to support multiple groups and maybe mix of groups and selectors for one policy. Then we still need an appliedTo struct for that?

@Dyanngg
Copy link
Contributor Author

Dyanngg commented Dec 15, 2020

/test-all

Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
But I'd like to confirm that we allowed creating policies that has empty appliedTo before and the change will make there will be at least one appliedTo in either policy spec or all of rule spec, right?

@Dyanngg
Copy link
Contributor Author

Dyanngg commented Dec 15, 2020

LGTM
But I'd like to confirm that we allowed creating policies that has empty appliedTo before and the change will make there will be at least one appliedTo in either policy spec or all of rule spec, right?

Correct. #1359 ensures that for Antrea-native policies, the appliedTo field has to be specified at policy level, though does not require it to not be an empty list. But realistically I believe it makes sense to check that there is at least one appliedTo in either policy spec or all of rule spec.

@abhiraut
Copy link
Contributor

abhiraut commented Dec 15, 2020

btw I am still wondering if we should support appliedTo per rule with regular selectors or keep it for incoming Group CRDs? or allow both? in that case we may need to propose two fields
ie

appliedTo:
  - podSelector: {}

or

appliedTo:
  - group: <groupName>

@jianjuns any thoughts on this?

@abhiraut
Copy link
Contributor

btw I am still wondering if we should support appliedTo per rule with regular selectors or keep it for incoming Group CRDs? or allow both? in that case we may need to propose two fields
ie

appliedTo:
  - podSelector: {}

or

appliedTo:
  - group: <groupName>

@jianjuns any thoughts on this?

noticed @jianjuns latest reply.. so we need to support hybrid, in that case maybe we need to formally propose the AppliedTo struct as Jianjun was suggesting.
And I assume we introduce a new "appliedTo" like field for groups then?

@jianjuns
Copy link
Contributor

@abhiraut: what is the plan for NP appliedTo? We should NP and rule the same right?
Again do you think we should have a separate AppliedTo struct that includes all selectors and groups?

@jianjuns
Copy link
Contributor

Guess I need to understand your ideas first.

@abhiraut
Copy link
Contributor

abhiraut commented Dec 15, 2020

Guess I need to understand your ideas first.

i was thinking of the following, if we want to support both groups and selectors

type AppliedTo struct {
  PodSelector *metav1.LabelSelector
  NamespaceSelector *metav1.LabelSelector
  Group *string // Reference to the Group/ClusterGroup
}

although this would still require some validation on the referenced Group to not have invalid selectors like IPBlock

@jianjuns
Copy link
Contributor

For NP appliedTo, do you plan to support both group and selectors?

Another question - do we want to support multiple groups?

@abhiraut
Copy link
Contributor

For NP appliedTo, do you plan to support both group and selectors?

Another question - do we want to support multiple groups?

does the following make sense:

type AppliedTo struct {
  PodSelector *metav1.LabelSelector
  NamespaceSelector *metav1.LabelSelector
  Group *string // Reference to the Group/ClusterGroup
}

type NetworkPolicySpec struct {
  AppliedTo []AppliedTo
  // other fields
  ...
}

type Rule struct {
  AppliedTo []AppliedTo
  // other fields
  ...
}

Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

I believe any change of type for the AppliedTo fields would belong in a separate PR (requires an API version change).

We should consider adding unit tests for conversion functions as we introduce more to make sure they behave correctly. I believe upstream K8s does the same.

@@ -190,6 +191,10 @@ type NetworkPolicyRule struct {
// EnableLogging is used to indicate if agent should generate logs
// when rules are matched. Should be default to false.
EnableLogging bool
// AppliedToGroups is a list of names of AppliedToGroups to which this rule applies.
// Cannot be set in conjunction with NetworkPolicy.AppliedToGroups of the NetworkPolicy
// that this Rule is referred to.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that this Rule belongs to

@jianjuns
Copy link
Contributor

@abhiraut I feel "[]AppliedTo" looks strange. ApplitedTo sounds like a singular to include all entities.

Of course the AppliedTo strcut change should not be in this PR (we are just using this PR to discuss and probably let us move to another thread). I think everyone is on the same page here.

@Dyanngg Dyanngg merged commit 2f55e19 into antrea-io:master Dec 17, 2020
zyiou pushed a commit to zyiou/antrea that referenced this pull request Dec 21, 2020
* Add appliedTo field in rules and update validationWebook

* Add appliedTo per rule handling in controller and agent

* Add omitempty to appliedTo fields and address test failures

* Add testcases for appliedTo per rule

* Address comments
zyiou pushed a commit to zyiou/antrea that referenced this pull request Dec 21, 2020
* Add appliedTo field in rules and update validationWebook

* Add appliedTo per rule handling in controller and agent

* Add omitempty to appliedTo fields and address test failures

* Add testcases for appliedTo per rule

* Address comments
antoninbas pushed a commit that referenced this pull request Dec 23, 2020
* Add appliedTo field in rules and update validationWebook

* Add appliedTo per rule handling in controller and agent

* Add omitempty to appliedTo fields and address test failures

* Add testcases for appliedTo per rule

* Address comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Antrea-native policies should support appliedTo on a per rule basis
8 participants