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

Support serviceAccountSelector for NetworkPolicy #2927

Closed
leonstack opened this issue Oct 22, 2021 · 4 comments · Fixed by #3044
Closed

Support serviceAccountSelector for NetworkPolicy #2927

leonstack opened this issue Oct 22, 2021 · 4 comments · Fixed by #3044
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. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@leonstack
Copy link
Contributor

leonstack commented Oct 22, 2021

Describe the problem/challenge you have
Some workloads have same serviceAccount that have same permission to access some resources, for now if we want to setup allow NetworkPolicy for these workloads to access the resources, we need create several NetworkPolicies (or with several group) to match all the workloads, this is a little complicate.

Describe the solution you'd like
We can use serviceAccountSelector to match the workloads, then there will be only one NetworkPolicy created, simplify the operation for NetworkPolicy setup.

@leonstack leonstack added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 22, 2021
@antoninbas
Copy link
Contributor

NPL means the "NodePortLocal" feature in the context of Antrea, but I am pretty sure that it is not what you are referring to here. I think you mean NetworkPolicies, or more precisely Antrea-native NetworkPolicies.

I think I understand the request, but I am not sure why you wouldn't use a common label for all these workloads (which share the same serviceAccount) so that you can define a single NetworkPolicy which applies to / selects all of them?

However, I see that Calico actually supports the feature you are describing: https://docs.projectcalico.org/security/service-accounts. I'm tagging @abhiraut to see if he has thoughts about this.

@antoninbas antoninbas added the area/network-policy/api Issues or PRs related to the network policy API. label Oct 22, 2021
@leonstack
Copy link
Contributor Author

leonstack commented Oct 23, 2021

NPL means the "NodePortLocal" feature in the context of Antrea, but I am pretty sure that it is not what you are referring to here. I think you mean NetworkPolicies, or more precisely Antrea-native NetworkPolicies.

Ops, thanks for pointing it out, it's NetworkPolicy.
In some zero-trust infrastructure, serviceAccount is using to identity who they are, so with the NetworkPolicies for the serviceAccount, it will be more convenient.

@leonstack leonstack changed the title Support serviceAccountSelector for NPL Support serviceAccountSelector for NetworkPolicy Oct 25, 2021
@abhiraut
Copy link
Contributor

Thanks for raising this issue. there are folks interested in upstream network policy group to support this.. https://docs.google.com/document/d/1Q_iI26PEEsU7seyIOExxo5LdFbeAsXI_A2W_ShIQ9_8/edit#heading=h.vuvj3ejktgmi

@GraysonWu is also actively thinking on this topic so we can support this sooner with Antrea-native policies.

@github-actions
Copy link
Contributor

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 24, 2022
GraysonWu added a commit to GraysonWu/antrea that referenced this issue Feb 16, 2022
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]>
antoninbas pushed a commit that referenced this issue Feb 17, 2022
Fixes #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]>
bangqipropel pushed a commit to bangqipropel/antrea that referenced this issue Mar 2, 2022
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]>
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. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants