TrueFoundry by default provisions a single external load-balancer for one Kubernetes cluster. This is provisioned automatically by the tfy-istio-ingress helm chart installed by TrueFoundry which creates a Kubernetes service of type LoadBalancer
. You can find the configuration of this service in Deployments > Helm > tfy-istio-ingress (Make sure you are filtering for the desired cluster)
You can click on the three dots to understand the configuration.
If you want to modify any of your load-balancer settings, you will have to edit this configuration according to the guide mentioned below.
The loadbalancer can be modified using annotations on the gateway object. Below is an example of possible modifications that you can do. To get a complete list of annoations - check here
As mentioned above, if you want the loadbalancer to be external, add the following annotation:
If you convert the load balancer from internal to external or vice-versa, the loadbalancer will be recreated and you will have to remap your DNS.
If you want it to be internal, the following annotation should be added:
If you want to restrict the access to the load balancer to a specific IP address, you can add the following annotation:
The default configuration creates an external load-balancer:
To make the loadbalancer internal, add the annotation as follows:
The default configuration creates an external load balancer with the below configuration
To make the load balancer internal
By default load balancer will be created without an external IP address in the case of generic cluster.
Run metalLB to assign an IP address to the load balancer.
Once the load balancer gets the IP address assign the certificates for it to terminate TLS traffic. For that you can use cert-manager or bring your own certificates.
istio-system
namespace.Passing those secrets in the tfy-istio-ingress
in tfyGateway.spec.servers[1].tls.credentialName
Each installation of tfy-istio-ingress
creates a load balancer. If you want to deploy multiple multiple load-balancers, for e.g. one internal and one external, you can clone the current tfy-istio-ingress
application in the same namespace istio-system
, change the tfyGateway.Name
to something else other then default tfy-wildcard
and update the tfyGateway.spec.Selector
with the new name of the application.
For e.g. if you clone the tfy-istio-ingress
a new application with the name tfy-istio-ingress-1
will be created , update the tfyGateway.Name
to a new name and the tfyGateway.spec.Selector
to
Once the ingress is installed, it will automatically create another loadbalancer whose IP you can get using kubectl get svc -n istio-system
.
We can configure Istio to apply authentication at a gateway level. This will work only if you are accessing the service using the DNS provided in Istio and not access the service directly from within the cluster. This process is a bit complicated, and you should only do this if you really want to enable authentication at an istio gateway level.
Create a RequestAuthentication resource to ensure that the JWT issuer and Audience are correct.
Create an AuthorizationPolicy that will reject any requests with an empty JWT.
You can read the Istio docs: https://istio.io/latest/docs/reference/config/security/request_authentication/ for further customization or making it work with your own IdP.
TrueFoundry by default provisions a single external load-balancer for one Kubernetes cluster. This is provisioned automatically by the tfy-istio-ingress helm chart installed by TrueFoundry which creates a Kubernetes service of type LoadBalancer
. You can find the configuration of this service in Deployments > Helm > tfy-istio-ingress (Make sure you are filtering for the desired cluster)
You can click on the three dots to understand the configuration.
If you want to modify any of your load-balancer settings, you will have to edit this configuration according to the guide mentioned below.
The loadbalancer can be modified using annotations on the gateway object. Below is an example of possible modifications that you can do. To get a complete list of annoations - check here
As mentioned above, if you want the loadbalancer to be external, add the following annotation:
If you convert the load balancer from internal to external or vice-versa, the loadbalancer will be recreated and you will have to remap your DNS.
If you want it to be internal, the following annotation should be added:
If you want to restrict the access to the load balancer to a specific IP address, you can add the following annotation:
The default configuration creates an external load-balancer:
To make the loadbalancer internal, add the annotation as follows:
The default configuration creates an external load balancer with the below configuration
To make the load balancer internal
By default load balancer will be created without an external IP address in the case of generic cluster.
Run metalLB to assign an IP address to the load balancer.
Once the load balancer gets the IP address assign the certificates for it to terminate TLS traffic. For that you can use cert-manager or bring your own certificates.
istio-system
namespace.Passing those secrets in the tfy-istio-ingress
in tfyGateway.spec.servers[1].tls.credentialName
Each installation of tfy-istio-ingress
creates a load balancer. If you want to deploy multiple multiple load-balancers, for e.g. one internal and one external, you can clone the current tfy-istio-ingress
application in the same namespace istio-system
, change the tfyGateway.Name
to something else other then default tfy-wildcard
and update the tfyGateway.spec.Selector
with the new name of the application.
For e.g. if you clone the tfy-istio-ingress
a new application with the name tfy-istio-ingress-1
will be created , update the tfyGateway.Name
to a new name and the tfyGateway.spec.Selector
to
Once the ingress is installed, it will automatically create another loadbalancer whose IP you can get using kubectl get svc -n istio-system
.
We can configure Istio to apply authentication at a gateway level. This will work only if you are accessing the service using the DNS provided in Istio and not access the service directly from within the cluster. This process is a bit complicated, and you should only do this if you really want to enable authentication at an istio gateway level.
Create a RequestAuthentication resource to ensure that the JWT issuer and Audience are correct.
Create an AuthorizationPolicy that will reject any requests with an empty JWT.
You can read the Istio docs: https://istio.io/latest/docs/reference/config/security/request_authentication/ for further customization or making it work with your own IdP.