In Kubernetes, network policies allow restricting traffic flow at the IP address or port level. By default, pods are non-isolated; they accept traffic from any source. The Appian operator supports conditionally restricting inbound traffic to site pods on a site-by-site basis via NetworkPolicy resources. This page details how to configure Appian custom resources to restrict traffic to/from Appian sites. It is aimed at self-managed customers running Appian on Kubernetes.
Note: Enforcement of network policies is implemented by network plugins. To use network policies, you must use a network plugin that supports NetworkPolicy resources such as Calico. Creating a NetworkPolicy resource without a controller that implements it will have no effect.
To restrict inbound traffic to a given site's pods, set the .spec.networkPolicies.enabled field to true
on the site's Appian custom resource:
1
2
3
4
5
6
7
apiVersion: crd.k8s.appian.com/v1beta1
kind: Appian
metadata:
name: appian
spec:
networkPolicies:
enabled: true
This will instruct the operator to create a variety of NetworkPolicy resources that target the site's pods.
This is done only as needed to restrict inbound traffic as much as possible. The exact specification of each component-specific NetworkPolicy depends on the topology of the site.
Let's say that you've followed the section above to restrict inbound traffic to Appian for security purposes, but also need to allow traffic from specific non-Appian pods or IP blocks.
This situation is common when exposing Appian outside of Kubernetes. In this case, traffic needs to be allowed to Appian's Webapp pods or its Apache Web Server (httpd) pods (if enabled).
The Appian operator and Appian custom resource definition support adding network policy ingress rules to the component-specific NetworkPolicy resources described above on a site-by-site basis via the .spec.[COMPONENT].additionalNetworkPolicyIngressRules fields on Appian custom resources. If httpd is disabled (the default), ingress traffic routes directly to Webapp, so the .spec.webapp.additionalNetworkPolicyIngressRules
field should be used. Otherwise, ingress traffic routes to httpd, so the .spec.httpd.additionalNetworkPolicyIngressRules
field should be used. Additionally, if RPA is enabled and inbound traffic has been restricted, then .spec.rpa.additionalNetworkPolicyIngressRules
should be used.
Each field accepts a list of networkingv1.NetworkPolicyIngressRule objects. The specification of each object's from
field depends on how Appian is exposed outside of Kubernetes. The specification of each object's ports
fields depends on whether or not httpd is enabled and, if disabled, how .spec.service.protocol is set.
RPA requires unrestricted access to the internet by default, with RPA reaching out to Maven repositories on the internet when it checks for 3rd party dependencies (JARs) for each robotic task execution. (See the RPA Repository Management page for more information.)
Alternatively, you can configure RPA to work in "offline"
mode in order to prevent RPA from connecting to the public internet. RPA will be fully functional in "offline"
mode; however, this may increase the export size for any Java-dependent Robotic Tasks.
To restrict RPA from communicating with the public internet, set the value for .spec.rpa.properties.rpa.artifact.resolution
to "offline"
. If the custom property is omitted, the default is "online"
.
1
2
3
4
5
6
7
8
apiVersion: crd.k8s.appian.com/v1beta1
kind: Appian
metadata:
name: appian
spec:
rpa:
properties:
rpa.artifact.resolution: "offline"
Restricting Traffic in Appian on Kubernetes