Host agent security considerations

The agent can be configured to accept TLS encrypted requests on its HTTP port 42699 and on its gRPC port 4317. See Setting up TLS Encryption for Agent Endpoint for more details.

During runtime, the agent creates temporary files, and stores additional libraries in $TMP/.instana on the host machine where it runs or inside application containers that the agent monitors. These files are accessed by monitored processes during runtime. Because monitored applications run with various user permissions, these files have wide access permissions. On Linux-based hosts and on container environments, the permissions are 777. On Windows-based hosts, these files are located in %TEMP%/instana, and have full access permissions for the user account that runs the application.

Because the Instana host agent needs to connect to application pods and list or open its own ports on bridge networks on the node where it is deployed, the host network access and host-level process ID lookup for infrastructure correlation are needed. This is equivalent to the permissions granted on Linux & Unix host environments and requires the following flags as set in the DaemonSet deployment:

• privileged: true: Provides full access to /proc without overlay, change UID/GID for JVM attachment, and access application namespaces.
• hostPID: true: Provides host-level PIDs in /proc. This setting is required for infrastructure correlation.
• hostNetwork: true: Provides access to host-level and bridge network interfaces.

In addition, when you install the host agent to OpenShift, the Security Context Constraint (SCC) is set to privileged to grant the aforementioned permissions.

When you deploy the host agent on Kubernetes, consider the following security aspects:

• The agent mounts host system directories on containers to support efficient diagnostics and enables necessary operational functions.
• The container's root file system requires write access to the host system to support essential operations and maintain functions.
• You cannot apply a seccomp profile to a container that is running with the privileged: true permission set in the container's securityContext setting. Privileged containers always run as Unconfined. For more information, see Restrict a Container's Syscalls with seccomp.

To make the Kubernetes sensor detect all resources and applications that are running in the Kubernetes cluster, configure cluster role rules as follows:

rules:
  - nonResourceURLs:
    - "/version"
    - "/healthz"
    verbs: ["get"]- apiGroups: ["batch"]
    resources:
      - "jobs"
      - "cronjobs"
    verbs: ["get", "list", "watch"]
  - apiGroups: ["extensions"]
    resources:
      - "deployments"
      - "replicasets"
      - "ingresses"
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources:
      - "deployments"
      - "replicasets"
      - "daemonsets"
      - "statefulsets"
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources:
      - "namespaces"
      - "events"
      - "services"
      - "endpoints"
      - "nodes"
      - "pods"
      - "replicationcontrollers"
      - "componentstatuses"
      - "resourcequotas"
      - "persistentvolumes"
      - "persistentvolumeclaims"
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources:
      - "endpoints"
    verbs: ["create", "update", "patch"]
  - apiGroups: ["networking.k8s.io"]
    resources:
      - "ingresses"
    verbs: ["get", "list", "watch"]