ARTIFACTORY: How to configure Kubernetes Ingress to allow Docker Port access

ARTIFACTORY: How to configure Kubernetes Ingress to allow Docker Port access

Products
Frog_Artifactory
Content Type
Installation_Setup
AuthorFullName__c
Ino Choi
articleNumber
000006510
FirstPublishedDate
2025-07-06T10:53:16Z
lastModifiedDate
2025-07-06
VersionNumber
1
Introduction 

This article provides step-by-step instructions for configuring a Kubernetes environment to allow Docker clients to access different Artifactory repositories via unique, dedicated TCP ports (e.g., artifactory.my-domain.com:6555).

It is important to note that the Ports Method is generally not the recommended approach in a Kubernetes environment. Most Ingress controllers, including ingress-nginx, are primarily designed for L7 (Layer 7) routing based on hostnames and URL paths.

However, if the Ports Method is a strict requirement for your environment, this guide will walk you through the necessary multi-layered network configuration. We will cover the setup for both the ingress-nginx controller and the Artifactory Helm chart's internal NGINX to enable this functionality. This guide is intended for users deploying Artifactory via the official Helm charts into a Kubernetes environment where ingress-nginx is the chosen Ingress controller.

Resolution 

This solution involves three main parts:
  1. Configuring Artifactory's Internal NGINX to listen on the custom ports and perform the necessary rewrites.
  2. Configuring the main ingress-nginx Controller to act as a TCP passthrough for the Docker ports while handling web traffic normally.
  3. Creating a simple Ingress resource for the Artifactory UI traffic.
Part 1: Configuring Artifactory's Internal NGINX
The first step is to configure the NGINX that runs alongside Artifactory to handle the port-based Docker traffic, including terminating the SSL/TLS connection.

IMPORTANT: Before you begin, ensure you have set the 'Custom Base URL' and the 'Docker Access Method' to 'Port' within the Artifactory UI's Administration pages, as these are required for this configuration to function correctly.
  • Create the Custom artifactory.conf File
    Create a complete, custom artifactory.conf file. This file must contain the default configuration for the Artifactory UI plus new, custom server blocks for each Docker port. The key is to use the full internal Kubernetes service names for proxying. Note the ssl keyword on the listen directive, which tells NGINX to handle encrypted traffic on this port.
    Example my-artifactory.conf:
 
# Start with the complete default artifactory.conf as a base, then add the new server blocks for each Docker port to the end of the file.

## Server configuration for 'test-local' Docker repo on port 6555
server {
    listen 6555 ssl;
    server_name artifactory.yourdomain.com;
    if ($http_x_forwarded_proto = '') { set $http_x_forwarded_proto  $scheme; }
    rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/test-local/$1/$2;
    chunked_transfer_encoding on;
    client_max_body_size 0;
    location / {
        proxy_read_timeout  2400s;
        proxy_pass_header   Server;
        proxy_cookie_path   ~*^/.* /;
        proxy_pass          http://router;
        proxy_set_header    X-JFrog-Override-Base-Url $http_x_forwarded_proto://$host:$server_port;
        proxy_set_header    X-Forwarded-Port  $server_port;
        proxy_set_header    X-Forwarded-Proto $http_x_forwarded_proto;
        proxy_set_header    Host              $host;
        proxy_set_header    X-Forwarded-For   $proxy_add_x_forwarded_for;
    }
    location ~ ^/artifactory/ {
        proxy_pass    http://artifactory;
    }
}

## Server configuration for 'prod-local' Docker repo on port 6556 (Example)
server {
    listen 6556 ssl;
    server_name artifactory.yourdomain.com;
    if ($http_x_forwarded_proto = '') { set $http_x_forwarded_proto  $scheme; }
    rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/prod-local/$1/$2;
    chunked_transfer_encoding on;
    client_max_body_size 0;
    location / {
        proxy_read_timeout  2400s;
        proxy_pass_header   Server;
        proxy_cookie_path   ~*^/.* /;
        proxy_pass          http://router;
        proxy_set_header    X-JFrog-Override-Base-Url $http_x_forwarded_proto://$host:$server_port;
        proxy_set_header    X-Forwarded-Port  $server_port;
        proxy_set_header    X-Forwarded-Proto $http_x_forwarded_proto;
        proxy_set_header    Host              $host;
        proxy_set_header    X-Forwarded-For   $proxy_add_x_forwarded_for;
    }
    location ~ ^/artifactory/ {
        proxy_pass    http://artifactory;
    }
}
 
  • Create a ConfigMap from the File
    Package the configuration file you just created into a Kubernetes ConfigMap.
 
kubectl create configmap my-artifactory-nginx-config --from-file=artifactory.conf=my-artifactory.conf -n <your-artifactory-namespace>
 
  • Update the Artifactory values.yaml File
    Update your Artifactory values.yaml file to enable NGINX, configure SSL, point to your custom ConfigMap, and expose the new service ports.
    Example artifactory-values.yaml:
nginx:
  enabled: true
  customArtifactoryConfigMap: "my-artifactory-nginx-config"
  tlsSecretName: "your-tls-secret"
  # Expose the custom ports on the chart's NGINX service
  service:
    type: ClusterIP
    ssloffload: true
    
    customPorts:
      - name: docker-test   # A meaningful label for the port
        port: 6555         # The port the service will expose
        targetPort: 6555   # The port on the NGINX pod to send traffic to
        protocol: TCP

      - name: docker-prod    # Another meaningful label
        port: 6556
        targetPort: 6556
        protocol: TCP
 
  • Apply the changes by running helm upgrade for your Artifactory release with the updated values.yaml.
  • Make sure to define the Custom Base URL under the Administration - General Management - Settings page in the Artifactory UI.
  • Make sure to set the Docker Access Method to “Port” under the Administration - Artifactory Settings - HTTP Settings page in the Artifactory UI.

Part 2: Configuring the ingress-nginx Controller

Next, configure your main, cluster-wide ingress-nginx controller to handle the different types of traffic. This is typically done by providing a custom values.yaml when installing or upgrading the ingress-nginx Helm chart.
  • HTTP/S Traffic (UI): Will be handled by the Ingress resource.
  • Docker Traffic (Custom Ports): Will be handled by TCP Passthrough.
Example ingress-nginx-custom-values.yaml:
controller:
  service:
    type: LoadBalancer
    # Expose the Docker ports on the main external Load Balancer
    ports:
      docker-test: 6555
      docker-prod: 6556

  # Configure TCP Passthrough for the Docker ports
  tcp:
    # Map external port 6555 to the internal Artifactory NGINX service on port 6555
    "6555": "<your-artifactory-namespace>/<your-helm-release-name>-artifactory-nginx:6555"
    # Map external port 6556 to the internal Artifactory NGINX service on port 6556
    "6556": "<your-artifactory-namespace>/<your-helm-release-name>-artifactory-nginx:6556"
Install or upgrade your ingress-nginx controller using this file to apply the settings.

Part 3: Creating the Ingress Resource for UI Traffic
Finally, create a simple Ingress resource whose job is to route the UI traffic. The Docker traffic is handled by the TCP passthrough and does not need an Ingress rule.
There are two methods to create this Ingress resource: directly within the Artifactory Helm chart's values.yaml or as a separate file.

Option 1: Use the Helm Chart's customIngress Value

This method keeps all your configuration within the Artifactory values.yaml file, which can be simpler for tracking changes.
 
  • Edit your values.yaml file and add the customIngress section. The structure mirrors the Ingress spec.
ingress:
  enabled: true
  customIngress: |
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: artifactory-ui-ingress
      namespace: <your-artifactory-namespace>
    spec:
      ingressClassName: nginx
      rules:
      - host: artifactory.yourdomain.com
        http:
          paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                # This points to the internal Artifactory NGINX service
                name: <your-helm-release-name>-artifactory-nginx
                port:
                  # The service's standard HTTP port
                  number: 80
      tls:
      - hosts:
        - artifactory.yourdomain.com
        secretName: your-tls-secret
 
  • Apply the changes by running helm upgrade for your Artifactory release with the updated values.yaml.
Option 2: Create a Separate Ingress Manifest
This method keeps your routing configuration separate from your application configuration, which can be easier to manage.
  • Keep Chart’s ingress disabled.
    ingress:
      enabled: false
    
    
 
  • Create a file: (e.g. artifactory-ui-ingress.yaml)
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: artifactory-ui-ingress
      namespace: <your-artifactory-namespace>
    spec:
      ingressClassName: nginx
      rules:
      - host: artifactory.yourdomain.com
        http:
          paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                # This points to the internal Artifactory NGINX service
                name: <your-helm-release-name>-artifactory-nginx
                port:
                  # The service's standard HTTP port
                  number: 80
      tls:
      - hosts:
        - artifactory.yourdomain.com
        secretName: your-tls-secret

  • Apply this manifest to your cluster.
    kubectl apply -f artifactory-ui-ingress.yaml -n <your-artifactory-namespace>
    
    
Your ingress-nginx controller will read this rule and direct web traffic for artifactory.yourdomain.com to your Artifactory UI, while the TCP passthrough will handle the Docker connections on their respective ports.