Release 1.19.6

Version 1.19.6

What's New

Support for alternate backends for OpenShift routes

When an OpenShift route is supported by multiple services, alternate backends are used for specifying the additional services.
Alternate backends for OpenShift routes are now supported by Citrix ingress controller. Citrix ADC is configured according to the weights provided in the routes definition and traffic is distributed among the service pods based on those weights. For more information, see Alternate Backend Support.

Enhancements

• Now, Citrix ingress controller supports binding default certificates in OpenShift routes.
• The default value for the environment variable NS_PROTOCOL is now changed to HTTPS and the default value for NS_PORT is now changed to 443.
• Earlier, front-end profiles for TCP, HTTP, and SSL were supported but the profile must be specified as part of a separate ingress called the front-end ingress. With this enhancement, you can specify front-end profiles as part of the regular ingress. This enhancement also helps to handle any conflicts that can arise from different ingresses belonging to the same content switching virtual server in a pre-determined way. For more information, see Configure HTTP, TCP, or SSL profiles on Citrix ADC.
• Now, Citrix ingress controller supports configuring global level front-end profiles for TCP, HTTP, and SSL using ConfigMap variables. Three new variables, FRONTEND_TCP_PROFILE, FRONTEND_HTTP_PROFILE, and FRONTEND_SSL_PROFILE, are added which can be used to set the front-end TCP, HTTP, and SSL profiles. For more information, see Configure HTTP, TCP, or SSL profiles on Citrix ADC.

Fixed issues

• In OpenShift routes, the targetPort field in the route represents the port of the pod. However, Citrix ingress controller was treating targtePort as a service port similar to the way it treats ingress. Hence, Citrix ingress controller was unable to handle destination services where targetPort is different from the service port. This issue is fixed now.

Release 1.18.5

Version 1.18.5

What's New

HTTP callout using rewrite and responder CRD

An HTTP callout allows Citrix ADCs to generate and send an HTTP or HTTPS request to an external server as part of the policy evaluation and take the appropriate action based on the response obtained from the external server. Now, you can use the rewrite and responder CRD to initiate HTTP callout requests from a Citrix ADC.
For more information, see the HTTP callout documentation.

Kubernetes version 1.22 support

Citrix ingress controller now supports Kubernetes version 1.22. With Kubernetes version 1.22, support for some of the older API versions are removed. For detailed information on the changes, see the Kubernetes documentation.
Citrix ingress controller deployment YAMLs and Helm charts are updated in this release to support these changes.

Enhancements

Earlier, for WAF CRD spec.application_type attribute can be of type string or array. Now, only type array is supported. If WAF CRD is used, make sure that this attribute is used with the attribute type as array. The WAF policy will fail if the spec.application_type attribute is used as string and not changed to array.

Release 1.17.13

Version 1.17.13

What's New

Configure cross-origin resource sharing policies

Cross-origin resource sharing (CORS) is a mechanism allows a web application running under one domain to securely access resources in another domain. You can configure CORS policies on Citrix ADC using Citrix ingress controller to allow one domain (the origin domain) to call APIs in another domain. For more information, see the cross-origin resource sharing CRD documentation.

Analytics support with GitOps

Web insight based analytics is now supported with GitOps (API Gateway CRD).
When you use GitOps, the following web insight parameters httpurl, httpuseragent, httphost, httpmethod, and httpcontenttype are enabled by default. For more information, see the Deploy API Gateway with GitOps documentation.

Ingress class support for CRDs

For CRDs, the ingress class feature is now supported. Earlier, Citrix CRD instances are applied by all instances of Citrix ingress controllers within a Kubernetes cluster. Now, you can optionally specify the ingress class using the spec.ingressclass field. When the ingress class is specified, only the Citrix ingress controller instance which is started with the given ingress class using the --ingress-classes argument processes the CRD resource. If the ingress class is not specified, then the earlier behavior persists.

DNS resolution on Citrix ADC

Now, you can configure Citrix ADC as a DNS server to resolve host names specified in the Ingress using Citrix ingress controller. A new environment variable NS_CONFIG_DNS_REC is introduced which can be configured as an argument to Citrix ingress controller.

For more information, see deploy Citrix ingress controller.

Logging support with rate limit CRD

You can now enable logging for observability with the rate limit CRD. For more information, see the rate limit CRD documentation.

Added support for protection against SQL injection using the grammar pattern

Now, protection against SQL injection using the grammar pattern is added to WAF CRD. For more information, see the WAF CRD documentation.

Fixed issues

• When Citrix ingress controller is restarted, CRD bindings for a load balancing virtual server created by content routing CRD was lost. This issue is fixed now.

• Earlier, https monitoring was not working when specified in a global traffic policy (GTP). This issue is fixed now.

• A backup content switching virtual server binding was lost in some scenarios when the traffic-policy deployment type is failover. This issue is fixed now.

• Earlier, the monitor configuration was not getting deleted when the GTP was deleted. This issue is fixed now.

• Earlier, multiple ingresses were not supported with WAF and bot CRDs. This issue is fixed now.

• When a service of type load balancer was processed but not configured due to any error and a delete event of that service was received, Citrix ingress controller was crashing. This issue is fixed now.

• Earlier, when the HTTPRoute back-end is used in the Ingress and redirect option is enabled, it worked only for the first host name. This issue is fixed now.

• Earlier, Citrix ingress controller modifies the SNIEnable and ClientAuth fields of a preconfigured SSL profile depending on the certificate binding. Now, Citrix ingress controller is excluded from modifying the preconfigured SSL profile.

• Sometimes, there is inconsistency in service group members of the Listener CRD back-end if the replica goes to zero. This issue is fixed.

Release 1.16.9

Version 1.16.9

What's New

SIP UDP support

Now, session initiation protocol over UDP (SIP UDP) is supported as layer 4 load balancing protocol for ingress with the ingress.citrix.com/insecure-service-type annotation and for service of type LoadBalancer with the service.citrix.com/service-type annotation.

For more information, see the Annotation documentation.

Fixed issues

• While upgrading Citrix ingress controller from versions prior to 1.15.12, some of the already bound certificate keys were getting deleted. Now, this issue is fixed.

• Sometimes, already bound CRDs were unbounded when Citrix ingress controller is restarted. This issue is fixed now.

• When Citrix ingress controller is started with the IPAM controller argument but IPAM controller was not running and the ingress was modified, then Citrix ingress controller may fail. This issue is fixed now.

Release 1.15.12

Version 1.15.12

Fixed issues

• Errors while applying rewrite CRD was causing a loop because Citrix ingress controller was not tracking generation for failed events. Even for failed resources, Citrix ingress controller was sending status updates to the CRD which resulted in a loop. This issue is fixed now.

• When multiple Citrix ingress controllers are deployed with different ingresses or service classes in the cluster, VIP CRD instances were created and deleted in a loop. This issue is fixed now.

• Any addition or deletion of secrets was triggering reconfiguration of all ingresses of the same frontend-ip and flooding of messages. This issue is fixed now.

• Ingress status was not getting updated in Citrix ADC CPX deployment for BGP. This issue is fixed.

• The default configuration of the SSL termination annotation service.citrix.com/ssl-termination-<index> was not working. This issue is fixed now.

• Exceptions were not handled properly while deleting profiles. Now, exceptions are handled properly.

• Now, WAF CRD raises a warning when the IP reputation feature is used along with WAF in deployments where Citrix ingress controller is deployed along with Citrix ADC CPX. The IP reputation feature is not supported in Citrix ADC CPX.

• Earlier, the SSL certificate key mentioned in OpenShift routes were present in Citrix ingress controller logs. Now, it is fixed.

• Inconsistent naming of load balancing virtual server entities created for OpenShift routes is now fixed.

• If an ingress resource has http.paths specified, but a service back-end is not specified it resulted in an exception. This issue is fixed now.

• If an ingress is deleted, all other ingresses of the same front-end IP address try to reconcile the certificates with the Citrix ADC. If there is any failure in certificate addition, it was resulting in flooding of messages. This issue is fixed now.

• If an ingress with multiple rules with different paths has the same service back-end which is also same as the default back-end, it results in incorrect priority while binding the content switching policy in Citrix ADC. This issue is fixed now.

Enhancements

• Ingress resource version is now stored at the load balancing virtual server level. With this enhancement, when Citrix ingress controller restarts only ingresses which got modified are reconfigured. Earlier, this information was maintained at the content switching virtual server level and any change for any ingress under the content switching virtual server used to cause reconfiguration for all ingresses.

  Note: During the first upgrade, the resource-version information is not available and this optimization does not help.

• When Citrix ingress controller restarts, it detects ingresses which are modified after the last restart and only reconfigures those ingresses by deleting and adding them one by one. Earlier, all ingresses were deleted at once and then recreated later, resulting in longer downtime.

• Priority calculation for content switching policies is now optimized by introducing a cache in Citrix ingress controller.

• To track the synchronization time, meaningful logs are added.

• Earlier, Citrix ingress controller would process the ingress even if only the status field is changed. Now, Citrix ingress controller does not configure the ingress if only the status field is changed.

• Now, Citrix ingress controller identifies whether the default SSL profile is enabled on the Citrix ADC during bootup time and uses that information to enable the SNIenable field for SNI certificates. In case the default profile is enabled, Citrix ingress controller uses the SSL profile to enable the SNI. Otherwise, the SSL virtual server is used to enable SNI.

  Note: In case the default SSL profile is enabled after Citrix ingress controller is started, Citrix ingress controller needs to be rebooted for the correct SSL configuration.

• When Citrix CPX is used as sidecar, now the default SSL profile is enabled by default. With this enhancement, Citrix ADC CPX can support advanced SSL features such as TLS1.3 using SSL profiles.

Release 1.14.17

Version 1.14.17

What's New

Advanced content routing for Ingress using the HTTPRoute CRD

Now, Citrix supports configuring the HTTP route CRD resource as a resource backend in Ingress. By default, Ingress supports only limited content routing capabilities like path and host based routing. Using this feature, you can extend advanced content routing capabilities to Ingress and perform content switching based on query parameters, cookies, HTTP headers, and other Citrix ADC custom expressions.

For more information, see the Advanced content routing for Ingress using the HTTPRoute CRD documentation.

IP address management using the Citrix IPAM controller for Ingress resources

For service of type LoadBalancer, you can automatically allocate IP addresses to services from a specified IP address range using the IPAM controller. Now, this functionality is extended to ingress resources as well. When the virtual IP address (VIP) is not specified for an Ingress resource and the IPAM controller is enabled, it allocates an IP address for the ingress resource from a specified range. The Citrix ingress controller configures the allocated IP address as a VIP in Citrix ADC MPX or VPX.
For more information, see the IP address management using the Citrix IPAM controller for Ingress resources documentation.

Authentication support with the content routing CRD

Authentication support is now extended with content routing CRD, where content routing CRDs are supported for configuring advance policies.
For more information, see the Auth CRD documentation.

IPSET support

An IPSET is a set of IP addresses, which are configured on the Citrix ADC appliance as Subnet IP addresses (SNIPs) or VIPs. Now, you can specify the name of the IPSET while configuring the content switching virtual server on a Citrix ADC using the Citrix ingress controller.

For more information, see the Annotation documentation.

Profile support for the Listener CRD

For HTTP, TCP, or SSL protocols, you can group a set of configurations specific to a protocol as a profile and apply it on the Citrix ADC. Now, HTTP, TCP, and SSL profiles are supported for the Listener CRD. The Listener CRD also supports the analytics profile which enables to export the transaction data to Citrix observability exporter.
For more information, see the Profile support for the Listener CRD documentation.

Fixed issues

• After a reboot of the Citrix ingress controller on the OpenShift platform, Citrix ADC entities like the content switching virtual server were deleted and re-created on the Citrix ADC. This issue is now fixed.

• While enabling some features in Citrix ADC, it may throw a NITRO exception with the error code 1097. This issue is fixed.

• Ingress with the version networking.k8s.io/v1 was not getting configured in the Amazon EKS cluster. This issue is fixed.

• While adding the Citrix observability exporter server, Citrix ADC may throw a NITRO exception with the error code 1335. This issue is fixed.

• While adding the Citrix ingress controller string map, Citrix ADC was throwing a NITRO exception due to the presence of "-" in the Kubernetes namespace. This issue is fixed in this release.

Known issues

A stand-alone Citrix ingress controller for configuring Citrix ADC VPX or MPX raises an exception when an ingress resource it supports has neither the frontend-ip annotation nor an ipam-range annotation. This issue has no functionality impact.

Release 1.13.20

Version 1.13.20

What's New

OpenID Connect

OpenID Connect (OIDC) is a simple identity layer on the top of the OAuth 2.0 protocol. Using the OIDC feature, clients can verify the identity of the end-user based on the authentication performed by an authorization server. You can also obtain the basic profile information about the end-user using this feature.
Now, the Auth CRD supports OIDC. For more information, see the Auth CRD documentation.

Ingress name attribute support in form based authentication

The Auth CRD supports form based authentication. In the form based authentication, the Ingress_name attribute is now supported. Using this attribute, you can specify the name of the Ingress for which you want to apply the form based authentication.
For more information, see the Auth CRD documentation.

Enhancements

With this enhancement, the GSE CRD is auto generated for an Ingress object if the service within the Ingress is referred in the GTP CRD instance and the status-loadbalancer-ip/hostname field is already populated. Earlier, the auto generation of the GSE CRD was supported only for a service of type LoadBalancer. For more information, see the Multi-cluster ingress and load balancing documentation.

Helm chart specific changes

For Helm chart specific changes, see the Helm chart release notes.

Release 1.13.15

Version 1.13.15

What's New

Policy based routing

When you are using a single Citrix ADC to load balance multiple Kubernetes clusters, the Citrix ingress controller adds static routes to establish connectivity between Citrix ADC and Kubernetes pods. However, when the pod CIDRs overlap there may be route conflicts. Using policy based routing you can route packets based on a specified criteria and avoid such route conflicts.

For more information, see the policy based routing documentation.

Simple canary with Ingress annotations

Canary release is a technique to reduce the risk of introducing a new software version in production by first rolling out the change to a small subset of users. Canary deployment is already supported using the Canary CRD. Now, Citrix also provides a simpler option for canary deployment using Ingress annotations. For more information, see the simple canary with Ingress annotations documentation.

Call Home enablement for the Citrix Ingress controller in Citrix ADC

The Call Home feature gathers information about the performance of a product and uploads them to a Citrix server which helps Citrix to diagnose issues and resolve them. Now, the Call Home feature available on Citrix ADC can be enabled for the Citrix ingress controller deployments. For more information, see the Call Home enablement for the Citrix ingress controller documentation.

Support for HTTP and HTTPs URL sources for OAS documents

Earlier, only Open API Specification (OAS) documents hosted in Git repositories were supported by the API Gateway CRD. Now, API Gateway CRD can also fetch OpenAPI Specification (OAS) documents from non-Git sources such as HTTP or HTTPs URLs. For more information, see Deploy API gateway using GitOps.

Ingress V1 enhancements and IngressClass support

With the Kubernetes version 1.19, the Ingress resource is generally available. As a part of this change, a new resource named as IngressClass is added to the ingress API. Using this resource, you can associate Ingress resources to specific Ingress controllers. Now, the Citrix ingress controller supports Ingress V1 enhancements and the IngressClass resource.

For more information, see the Ingress class support documentation.

Enhancements

The following environment variables are added in this release to the Citrix ingress controller:

• POD_IPS_FOR_SERVICEGROUP_MEMBERS: By default while configuring services of type LoadBalancer and NodePort on an external tier-1 Citrix ADC, the Citrix ingress controller adds NodeIP and NodePort as service group members. If this variable is set as True, pod IP address and port are added instead of NodeIP and NodePort as service group members.

• IGNORE_NODE_EXTERNAL_IP: While adding NodeIP for services of type LoadBalancer or NodePort on an external tier-1 Citrix ADC, the Citrix ingress controller prioritizes an external IP address over an internal IP address. When you want to prefer an internal IP address over an external IP address for NodeIP, you can set this variable to True.

Fixed issues

• Now, the --feature-node-watch argument is supported for Calico CNI.

• Earlier adding a certificate to the Citrix ADC may occasionally fail due to the presence of a stale intermediate CA certificate. Now, the Citrix ingress controller retries to add the certificate after deleting the intermediate CA certificate.

• When you delete OpenShift routes, the Citrix ingress controller may raise an exception. This issue is fixed now.

Release 1.12.2

Version 1.12.2

What's New

LDAP authentication support

Lightweight directory access protocol (LDAP) is an open and industry standard application protocol for accessing and maintaining distributed directory information services. A common use of LDAP is to provide a central place to store your user names and passwords. Now, the Auth CRD supports LDAP authentication. For more information, see the Auth CRD documentation.

Ingress status update for sidecar deployments

In cloud deployments, there are situations where a Citrix ADC CPX running along with the Citrix ingress controller is exposed using a cloud load balancer. In such scenarios, you can now update the ingresses that are configured on the Citrix ADC CPX with the IP address or host name of the cloud load balancer.

For more information, see the Ingress status update for sidecar deployments.

Enhancements

Shorter entity names

When the Citrix ingress controller adds the Citrix ADC entities, the previous naming format may result in ADC entities with large names even exceeding the name limits in Citrix ADC. Now, the naming format in the Citrix ingress controller is updated to shorten the entity names. In the updated naming format, a part of the entity name is hashed and all the necessary information is provided as part of the entity comments. For more information, see Entity name change.

Fixed issues

When the Citrix ingress controller tries to bind a server entity to a service group, if a server entity with the same IP address but a different name already exists, Citrix ADC throws an error. Now, this issue is fixed and the server is bound to the service group with the name of the existing server.

Helm chart specific changes

For Helm chart specific changes, see the Helm chart release notes.

Release 1.11.3

Version 1.11.3

What's New

Deploy API gateway using GitOps

With the GitOps solution for API gateway, you can use the API specification information created by developers for configuring API gateway policies. The GitOps mechanism is used to deliver the API specification document to the deployment environment.
Using the API gateway CRD provided as part of this solution, you can automatically bind single or multiple API gateway policies to APIs and apply them.

For more information, see Deploy API gateway using GitOps.

SAML authentication support

Security assertion markup language (SAML) is an XML-based open standard which enables authentication of users across products or organizations. Now, the Auth CRD supports SAML authentication. For more information, see the Auth CRD documentation.

Configure bot management policies

A bot is a software application that automates manual tasks. Using bot management policies, you can allow useful bots to access your cloud native environment and block access to the malicious bots. Now, you can configure bot management policies using the Bot CRD.
For more information, see the Bot CRD documentation.

Fixed issues

• The Citrix ingress controller was not updating Citrix ADC VPX with routes of the new nodes that were getting added to the Kubernetes cluster. This issue is fixed now.

• The Citrix ingress controller was not configuring all the endpoints if an endpoint event came before a service event. This issue is fixed now.