Shipa enables Operators and Developers to enforce and apply network policies at the framework and application layer levels.
The guide below gives operators details on which policies are available and how to enforce them at the framework level.
Operators can define network policies at the framework level, so these policies are automatically applied to applications when they are deployed to a specific framework.
Even though default network policies are applied at deployment time, operators can still give developers the autonomy to adjust these automated policies for individual applications post-deployment.
Framework level network policies can be defined when creating or editing frameworks through Shipa's dashboard, in the Network Policy Setup step.
When defining network policies on Shipa, you will be able to define both ingress and egress.
Shipa gives you flexibility on the policy modes that you can define when creating the framework and defining your network policies:
Each option is described below:
There is no constraint whatsoever in the traffic incoming/outgoing to/from the application. All communication is permitted.
All traffic incoming/outgoing the application is blocked. All communication is denied (no traffic can flow or reach the app).
Set of predefined policies built by Shipa to provide reasonable defaults to users to restrict the traffic of their applications. They intend to cover common use cases and can be combined depending upon the purpose:
traefik: Pre-defined policy based on k8 selectors (podSelectors/namespaceSelectors) that restricts the network traffic to flow through the ingress of the cluster only (a cluster using traefik as the ingress controller). Container-to-container communication is prohibited, and direct access from the “outside world” to the running containers of the apps is also restricted. The application is accessible through Shipa's generated endpoint
istio: Same as the previous pre-defined policy, but oriented to allow traffic only through ingress using istio as the controller.
kube-dns: Pre-defined policy that allows applications to resolve DNS-like addresses when other constraints exist. For example, if the traffic is enabled only for specific apps/services and the subject app needs to reach the DNS of another app (i.e. my.app.com/api), it will need the ability to resolve the suggested DNS.
When the policy mode allow-shipa-rules-only is used, only Shipa’s predefined rules can be selected and combined between each other. Other customizations won’t be allowed
It allows users to build their own network rules to have more granular control over which apps/services have access to their deployed app. The custom rules are the result of enabling:
Policy mode that allows combining “custom rules” and Shipa’s “pre-defined rules” together. Another level of customization
Shipa gives you 4 levels of policy restrictions to be applied to applications when defining network rules:
- Ports: the ports where your application can receive and send traffic through.
- Peers: it enables you to implement selectors specified in an ingress from section or egress to section. Options are Pod Selector, Namespace Selector, and IP Block.
- Apps: restricts communications between apps running on the same cluster.
- Frameworks: defines if applications from other frameworks can communicate with the application being deployed
When defining network policies at the framework level, you can either allow or block application owners to customize the network policies applied to their applications post-deployment.
This is available through the Allow app-level policies option of your framework workflow.
If this option is selected, application owners will have the option to customize individual application-level network policies enabled for their applications post-deployment.
Updated 6 months ago