Repository navigation
Replies: 1 comment 3 replies
|
What's the idea regarding The |
There is an expectation that eventually the our olm bundle will ship with a default policy that disables all ingress to all of the pods we create - or that even if we aren't doing that initially, that the namespace administrator should be able to create such a policy.
Yes. I'm not sure how permissive or first-class option driven we can be just based upon the ingress configuration - for anything beyond the openshift-default ingressclass we'd probably just have to rely on the user creating the rules rather than adding trying to capture the ingress pod namespace, labels, etc. as hints on our ingress configuration.
Yes with a couple of recent CVEs we talked briefly about having the server support some kind of allow list for endpoints that can be set by a realm admin, but rejected that too burdensome. This is even worse as it covers everything. The initial key is probably that we'll be secure by default. The namespace admin would always have the option of adding their own permissive ingress or egress networkpolicy as a workaround: https://kubernetes.io/docs/concepts/services-networking/network-policies/#allow-all-egress-traffic |
|
If you are suggesting removing the Network Policies from the CR spec (https://www.keycloak.org/operator/advanced-configuration#_network_policies) and asking the user/admin to create the network policy by hand, it sounds good to me! 👍 |
No, probably just the enabled flag. The suggestion about the namespace admin creating a more permissive networkpolicy would just be something we could document as an escape hatch if needed. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Starting a discussion, which we can use as the basis for an epic.
Building upon our initial support for NetworkPolicies, we should work towards satisfying best practies for stricter ingress / egress, see https://api.managed.entrust.com/csp/1.0.0/Kubernetes-CIS-benchmarks.html "Threat: Without network policies, any pod within the Openshift cluster can communicate freely with other pods, regardless of their intended level of access. Attackers or compromised pods can exploit this lack of restriction to move laterally within the cluster and potentially compromise critical components. In the absence of network policies, pods may have unrestricted communication with external networks, this can result in unintended data leakage, where sensitive information is transmitted to unauthorized destinations."
In particular based upon guidance from OpenShift we should cover:
cc @ahus1 @pruivo
All reactions