Feature: Allow permissive mode to be enabled/disabled per namespace

[keithmattix]

Please describe the Improvement and/or Feature Request

Permissive mode, while not as secure as the alternative, is the simplest way to get up and running with OSM. As such, many users may want to enable permissive mode on a per-namespace basis for various use-cases (e.g. multi-tenancy, selective onboarding, implicit trust in vendor namespaces, etc.)

Scope (please mark with X where applicable)

• Permissive Traffic Policy [X]

Possible use cases

[shashankram]

Hey @keithmattix, that's an interesting ask. One of the most basic requirements of permissive mode is to bootstrap application connectivity across the entire mesh with no configuration to simplify the onboarding experience. It seems like you are asking for a hybrid model of permissive mode and SMI co-existing within a mesh. Could you share more concrete examples of where this may help?

I understand this is doable, but one of the goals of the project has been to adopt simplicity instead of supporting multiple permutations for configuring the mesh policies. So I'd like to understand the use case and how common is it for users needing such a capability.

Thanks

[keithmattix]

Sure thing!

So essentially, OSM has two different trust models by default:

1. everything's trusted
2. nothing's trusted

My proposal is to add a third mode of operation: everything in my namespace is trusted. This matches Kubernetes convention where the namespace boundary is also the boundary for trust. This tertiary mode of execution is useful in scenarios where users may want to enable permissive mode for complex or brownfield workloads, but not for new services being deployed in other namespaces. Another example is one I've worked on personally: you may have namespaces for certain baseline/vendor services (e.g. redis cluster, grafana dashboard, vault) that have multiple intra-namespace components that are inherently trusted (perhaps because they were part of the same helm chart).

[shashankram]

Sure thing!

So essentially, OSM has two different trust models by default:

1. everything's trusted
2. nothing's trusted

My proposal is to add a third mode of operation: everything in my namespace is trusted. This matches Kubernetes convention where the namespace boundary is also the boundary for trust. This tertiary mode of execution is useful in scenarios where users may want to enable permissive mode for complex or brownfield workloads, but not for new services being deployed in other namespaces. Another example is one I've worked on personally: you may have namespaces for certain baseline/vendor services (e.g. redis cluster, grafana dashboard, vault) that have multiple intra-namespace components that are inherently trusted (perhaps because they were part of the same helm chart).

Do you see a need to allow permissive mode for apps across namespaces to communicate? If we can keep the configuration simple (all or just within selected namespaces), it seems reasonable. If it is intended to support more complex permutations, I would consider enabling them through a more granular policy mechanism.

[keithmattix]

@shashankram no - I think the we keep things simple and not try to handle the cross-namespace case. That's a security issue waiting to happen, and at that point, users should be configuring granular access rules anyway

[shashankram]

@shashankram no - I think the we keep things simple and not try to handle the cross-namespace case. That's a security issue waiting to happen, and at that point, users should be configuring granular access rules anyway

I don't think that should be a security issue as the intent would be explicit, but rather result in additional permutations that are not intuitive.

Note that the current permissive mode is about automatic service discovery and connectivity configuration vs explicit authorization policies. Apps still connect with each other in a trusted manner using mTLS, just that this happens without authorization policies. So the "trust" word can be misleading here.

If the ask is to support 2 forms of permissive mode (all namespaces, or within specific namespaces only), it seems more reasonable.

[keithmattix]

So the "trust" word can be misleading here. That's fair - my original comment was concerning the "default" (i.e. out of the box) trust modes when first installing OSM; apologies if that wasn't clear.

I see where you're coming from with simplifying the permutations for permissive mode, and I'm good with that. The 2 forms you described make sense 👍🏾

[allenlsy]

"trust" should be re-phrased as "allowed" or "authorized".

I agree with these 2 forms of permissive mode as well. We can scope this feature as follows:

The permission policies among namespaces should be stored somewhere. If permissive mode is enabled in MeshConfig, by default it should be the all-namespace permissive mode. If a namespace has specified permission policy, then only the allowed namespaces will be added as the source of the RBAC filter in their Envoy sidecars. In this way, if a namespace only sets itself as the allowed namespace, this matches the case that Keith mentioned in the issue description.

[phillipgibson]

I'm seeing a need to have authorization policy at the namespace level. More like creating firewall rules of what access is allowed to and endpoint by where it is originating from to destination (eg. Namespace) in addition to the type of operation verb (post, put, etc). Seems like if the HTTPRouteGroups can be extended with a namespace attribute for allow/deny that would work.

[github-actions[bot]]

Added default label size/needed. Please consider re-labeling this issue appropriately.

[github-actions[bot]]

This issue will be closed due to a long period of inactivity. If you would like this issue to remain open then please comment or update.

[github-actions[bot]]

Issue closed due to inactivity.