The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

/remove-lifecycle rotten

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

/reopen

@tssurya: Reopened this issue.

/remove-lifecycle stale

/remove-lifecycle rotten

@bowei you had some use cases for this right? We have an open issue where others had asked for serviceAccount match but we didn't get concrete use cases to start an enhancement or something.. wanna add more context to the issue?

/assign @tssurya

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

/lifecycle frozen

One thought -- I think the intent of some of this conversation is not necessarily add ServiceAccount match to the existing ANP functionality which is approximately another form of label match, but to figure out how auth via Service Account/identity a la service mesh would compose with the rest of the K8s policy ecosystem.

It feels like these two things are operating at different layers -- and it might be worthwhile thinking about the semantics as such. Concretely -- does it make sense to think of the mostly IP-based NP, ANP as a lower level of auth -- then -- identity-based auth kicks in.

 +-------+     +---------------+     +---------+             +---------+     +---------------+     +-------+
 | Pod A | --- | Identity/mesh | --- | ANP, NP | -~ (net) ~- | ANP, NP | --- | Identity/mesh | --- | Pod B |
 +-------+     +---------------+     +---------+             +---------+     +---------------+     +-------+

We have discussed a bit the potential solution combining NP with auth-policy, and the main idea is that you have to allow traffic with the NP (in this context same as ANP) first, and then apply auth-policy on top. I think that is the same as your picture. It looks a bit like identity/mesh happens before ANP, but I think that is only if you read it for egress, but you actually mean it in ingress terms, so ANP/NP happens first?

Having separate configs to do that may be annoying (e.g. ANP that allows traffic to podB and then AuthPolicy (imaginary API) that applies service-account-based policy). So we have discussed a possibility to express this intent in a single ANP with a serviceAccount pod selector, which could be handled by 2 separate controllers: first by the ANP controller to allow this on IP level, and then by the Auth controller/mesh on top of it. That only works for serviceAccounts though as it can be used for both layers

Yes -- the intent of the above diagram is to pose that the mental model we should use for an L7 policy is to be right next to the Pod, independent of the network level policies:

• It is always possible for the implementation to propagate the enforcement into the lower layers as an extra layer of security although we need to be careful about the definition of the behavior to make sure this is a transparent change.
• It's not clear that treating identity as another selector is sufficient for the use cases as it may not be expressible/identifiable at the raw networking layer vs the layer closer to the application.

@LiorLieberman