Security

This page describes how to configure security for Appian custom resources.

Configure a security context for a pod or container

In Kubernetes, a security context defines privilege and access control settings for a pod or container.

By default, the Appian operator will set the runAsUser fields of the containers it manages to the appropriate UID for the container's image. It will also set the fsGroup fields of the pods it manages to the appropriate GID for the pod's main container's image:

Setting runAsUser and fsGroup

To instruct the operator to set the runAsUser and/or fsGroup fields of the containers and pods it manages to a different value:

Set runAsUser in the .spec.[COMPONENT].securityContext field in the Appian CR configuration file.

Set fsGroup in the .spec.[COMPONENT].podSecurityContext field in the Appian CR configuration file.

For example, to instruct the operator to set fsGroup for Webapp to 2776, configure the following field:

1
2
3
4
5
6
7
8
apiVersion: crd.k8s.appian.com/v1beta1
kind: Appian
metadata:
  name: appian
spec:
  webapp:
    podSecurityContext:
      fsGroup: 2776

Omitting runAsUser and fsGroup

In some situations, you may want the operator to omit the runAsUser and/or fsGroup fields of the containers and pods it manages. This may be necessary if, for example, your cluster has a mutating admission webhook that should manage the fields.

To instruct the operator to omit the runAsUser and/or fsGroup fields of the containers and pods it manages:

Set the .spec.[COMPONENT].securityContext field but omit the runAsUser field in your Appian CR.

Set the .spec.[COMPONENT].podSecurityContext fields but omit the fsGroup field in your Appian CR.

For example, to instruct the operator to omit both the runAsUser and fsGroup fields for Webapp, configure the following fields:

1
2
3
4
5
6
7
8
apiVersion: crd.k8s.appian.com/v1beta1
kind: Appian
metadata:
  name: appian
spec:
  webapp:
    securityContext: {}
    podSecurityContext: {}

Restricting traffic

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 following sections detail how to configure Appian custom resources to restrict traffic to/from Appian sites.

Restricting inbound traffic

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.

• First it will create a default, deny-all ingress traffic NetworkPolicy that targets all of the site's pods.
• Then it creates a NetworkPolicy for each component that allows ingress traffic from other components or from other replicas of the same component to specific ports.

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.

Adding network policy ingress rules

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.

Running RPA in a restricted environment

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 this 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"

Container image security and vulnerability scanning

Appian routinely scans container images for CVEs and issues patches via hotfixes. Some customers like to run their own additional vulnerability scans. Any findings from such scans may be reported through a support case in MyAppian that includes a filled out copy of the Appian Vulnerability Submission Worksheet as described in KB-1447 Appian Cloud Vulnerability Testing.

Appian container images are hardened against applicable DISA STIGs.

Feedback