-
Notifications
You must be signed in to change notification settings - Fork 335
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
ExternalService
s shouldn't rely on the existence of a TrafficPermission
#6589
Comments
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. |
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. |
Should we close this now? @lukidzi ? |
This is still a problem, we shouldn't close this ☝️ |
I'm on Kuma version 2.4.3 and decided to migrate to ---
apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
namespace: kuma-system
name: allow-all-default
labels:
kuma.io/mesh: default
spec:
from:
- default:
action: AllowWithShadowDeny
targetRef:
kind: Mesh
targetRef:
kind: Mesh And now access to |
ExternalService
s shouldn't rely on the existence of a TrafficPermission
My idea to change the behavior:
I am not sure the best way to handle Auto ReachableServices, they are relying on the MTP so the user would need to define policy to have access or we could deliver all ES until there is a policy matching ES but it seems a bit complicated.
I don't think that we should define RBAC in outgoing traffic, just configure RBAC when using egress. Should we allow all when no policy or deny and require the user to define it? |
Description
When delete default TrafficPermission then ExternalServices don't work at all. Kuma generates outbounds for ES based on the TrafficPermission policy (no permission -> no outbound).
Can we just have a RBAC filter on the external service listener? What happens with Egress?
The text was updated successfully, but these errors were encountered: