TFY Agent is a lightweight agent that runs on the compute plane cluster and connects the cluster to the control plane. It allows the control plane to deploy applications (Service, Job, SSH Server, etc.) and track their status.
TFY Agent does not require an ingress/endpoint (Load balancer Service or Node Port) in your cluster. It initiates secure WebSocket connections to the control plane, which uses these connections for all activities. This allows your compute-plane cluster to be private and still be accessible from the control plane via the tfy-agent.

​
Architecture

TFY Agent consists of two parts both of which run independently and use a secure WebSocket connection to connect to the control plane.
  1. TFY Agent: This streams the state of the compute plane cluster to the control plane. This state includes but is not limited to the status of Nodes, Pods, Argo Applications, etc., in the cluster.
  2. TFY Agent Proxy: TFY Agent Proxy enables the control plane to access the compute plane cluster’s Kubernetes API server and create namespace (Workspace) and deploy applications to the compute plane cluster.

​
Installation and Configuration

TFY Agent is installed in the cluster using the tfy-agent helm chart. This chart is automatically installed using the scripts when you setup the compute plane. Both the agent and agent-proxy use Kubernetes RBAC objects to define the access to the underlying Kubernetes cluster.
  1. tfy-agent: The tfy-agent runs informers to stream Kubernetes resource changes and sends it to the control plane. To run informers, the TFY Agent must be able to list and watch those resource types across all the namespaces in the cluster.
By default, the tfy-agent listens to all the namespaces with the permissions listed in this file. TFY Agent only listens to resources and never makes any write actions on the cluster.
  1. tfy-agent-proxy: The TFY Agent Proxy enables the control plane to access and create resources on the compute cluster.
By default, the tfy-agent-proxy has all the permissions listed in this file. The default set of values provide complete access to the cluster - including the permissions to create/edit/delete resources on the cluster. We set up cluster-wide access for these namespaced resources.

​
Restrict Access on the cluster for tfy-agent and tfy-agent-proxy

The tfy-agent helm chart allows customizing the values to reduce the permissions on the cluster for tfy-agent and tfy-agent-proxy. To restrict access to certain namespaces only, you can make the following changes:
  1. Restrict tfy-agent and tfy-agent-proxy to only grant access to certain namespaces:
This can be done by setting the config.allowedNamespaces field in the values file in the helm chart. 
config:
  tenantName: your-tenant-name
  controlPlaneURL: your-controlplane-url
  clusterTokenSecret: your-cluster-token-secret
  allowedNamespaces:
    - tfy-agent
    - argocd
    - your-namespace
For tfy-agent,we still apply the cluster role to listen to all the resources across all namespaces, but the tfy agent will filter out any resource that is not part of the allowed namespaces. This is because Kubernetes informers do not allow to watch resources across only a few namespaces.
For tfy-agent-proxy, we setup role binding only for the allowed namespaces.
  1. Enable strict mode for tfy-agent-proxy to provide it only the permissions it needs to function correctly.
The minimum set of permissions required for the tfy-agent-proxy are listed here. To enforce the minimum set of permissions instead of complete access, you can set the tfyAgentProxy.clusterRole.strictMode field to true on the helm chart. 
config:
  tenantName: your-tenant-name
  controlPlaneURL: your-controlplane-url
  clusterTokenSecret: your-cluster-token-secret
tfyAgentProxy:
  clusterRole:
    strictMode: true
If you give a list of allowed namespaces using the config.allowedNamespaces field, we will always run on strict mode, regardless of the value of the tfyAgentProxy.clusterRole.strictMode field.In strict mode, we allow the control plane to create namespaces (Workspace) in the cluster. But if you give a list of allowed namespaces using the config.allowedNamespaces field, the control plane will not be allowed to create new namespaces.