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.- 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.
- 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.- 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.
- 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.
Customize TFY Agent Installation
Restrict Access on the cluster for tfy-agent and tfy-agent-proxy
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:
- Restrict tfy-agent and tfy-agent-proxy to only grant access to certain namespaces:
config.allowedNamespaces field in the values file in the helm chart.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.
- Enable strict mode for tfy-agent-proxy to provide it only the permissions it needs to function correctly.
tfyAgentProxy.clusterRole.strictMode field to true on the helm chart.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.Define which Istio Gateway to use for the Truefoundry components
Define which Istio Gateway to use for the Truefoundry components
If you are already using Istio in your cluster, Truefoundry can automatically read the Istio gateway configuration from the cluster and expose the corresponding domains in the service deployment form. This way developers don’t need to be aware of which Istio gateway to choose and the platform takes care of it.However, this assumes that both the gateways point to mutually exclusive domains - for e.g. gateway1 points to *.domain1.com and gateway2 points to *.domain2.com. If that is not the case, for e.g. gateway1 points to example.domain1.com and gateway2 points to *.domain1.com, then you will need to specify which gateway to use in case user chooses a domain like example.domain1.com for their service.In this case, you can specify the tiebreaker gateway in the tfy-agent helm chart. The tie-breaker gateway is chosen in case a domain matches to more than one gateway configured in the cluster.