-
Notifications
You must be signed in to change notification settings - Fork 369
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 service account selector support in ACNP #3044
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3044 +/- ##
==========================================
- Coverage 60.95% 54.97% -5.99%
==========================================
Files 266 371 +105
Lines 26508 50828 +24320
==========================================
+ Hits 16159 27943 +11784
- Misses 8597 20480 +11883
- Partials 1752 2405 +653
Flags with carried forward coverage won't be shown. Click here to find out more.
|
3a108a6
to
32414cc
Compare
32414cc
to
325491a
Compare
afdac9f
to
a1a6976
Compare
59be42d
to
b5480c4
Compare
af508b0
to
01782b4
Compare
// re-processed based on if they are affected by an added/updated/deleted | ||
// ServiceAccount. | ||
func (n *NetworkPolicyController) filterACNPsByServiceAccount(sa *v1.ServiceAccount) (acnps []*crdv1alpha1.ClusterNetworkPolicy) { | ||
acnpObjs, err := n.cnpInformer.Informer().GetIndexer().ByIndex(ServiceAccountsPeerIndex, HasServiceAccountsPeer) |
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.
@tnqn is there any issue with defining an index like this which simply partitions all the objects into 2 different groups?
d91c150
to
850c303
Compare
6c6b9c9
to
341a695
Compare
4f64e47
to
3399901
Compare
be55e6a
to
74b8879
Compare
// workloads in AppliedTo/To/From fields. | ||
// Cannot be set with any other selector. | ||
// +optional | ||
ServiceAccount *NamespacedName `json:"serviceAccount,omitempty"` |
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.
Good to see the API is really simple now!
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.
In #2755, the reference struct is named ServiceReference:
// ServiceReference represents a reference to a v1.Service.
type ServiceReference struct {
// Name of the Service
Name string `json:"name"`
// Namespace of the Service
Namespace string `json:"namespace,omitempty"`
}
I feel we should either unify them to NamespacedName
or create ServiceAccountReference
for this one. Is there any plan?
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.
Good catch. I slightly prefer to unify them to NamespacedName
which could be used to refer to other resources. And if we will use verbose API in the future then I guess this generic struct will still be needed.
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.
If unifying them sounds good, do you suggest unifying them in this PR or another one?
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 would suggest another PR.
6365995
to
1fd84d4
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 overall
// workloads in AppliedTo/To/From fields. | ||
// Cannot be set with any other selector. | ||
// +optional | ||
ServiceAccount *NamespacedName `json:"serviceAccount,omitempty"` |
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.
In #2755, the reference struct is named ServiceReference:
// ServiceReference represents a reference to a v1.Service.
type ServiceReference struct {
// Name of the Service
Name string `json:"name"`
// Namespace of the Service
Namespace string `json:"namespace,omitempty"`
}
I feel we should either unify them to NamespacedName
or create ServiceAccountReference
for this one. Is there any plan?
1fd84d4
to
87463cf
Compare
87463cf
to
1e1bf7e
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. Could you squash the commits and add commit message?
// workloads in AppliedTo/To/From fields. | ||
// Cannot be set with any other selector. | ||
// +optional | ||
ServiceAccount *NamespacedName `json:"serviceAccount,omitempty"` |
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 would suggest another PR.
Fixes antrea-io#2927 This PR added `serviceAccount` field support to ACNP. It uses Namespace and Name to specify a ServiceAccount and all Pods with this ServiceAccount will be selected as workloads. It could be used in egress `to`, ingress `from` and `appliedTo` of both policy and single rule. To implement this feature, this PR also added a custom label to all Pods internally, which looks like: `internal.antrea.io/service-account:[ServiceAccountName]`. And when process ACNP, `serviceAccount` will be translate to a `GroupSelector` with `Namespace` and `PodSelector` to select Pods we need. Signed-off-by: wgrayson <[email protected]>
1e1bf7e
to
42088ae
Compare
Thanks. Done. |
/test-all |
/test-integration |
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
Fixes antrea-io#2927 This PR added `serviceAccount` field support to ACNP. It uses Namespace and Name to specify a ServiceAccount and all Pods with this ServiceAccount will be selected as workloads. It could be used in egress `to`, ingress `from` and `appliedTo` of both policy and single rule. To implement this feature, this PR also added a custom label to all Pods internally, which looks like: `internal.antrea.io/service-account:[ServiceAccountName]`. And when process ACNP, `serviceAccount` will be translate to a `GroupSelector` with `Namespace` and `PodSelector` to select Pods we need. Signed-off-by: wgrayson <[email protected]>
Fixes #2927.
This PR added
serviceAccount
field support to ACNP. It usesNamespace and Name to specify a ServiceAccount and all Pods with this
ServiceAccount will be selected as workloads. It could be used in
egress
to
, ingressfrom
andappliedTo
of both policy and singlerule.
To implement this feature, this PR also added a custom label to
all Pods internally, which looks like:
internal.antrea.io/service-account:[ServiceAccountName]
. And whenprocess ACNP,
serviceAccount
will be translate to aGroupSelector
with
Namespace
andPodSelector
to select Pods we need.Signed-off-by: wgrayson [email protected]