Examples Ingress [Cloudflared] configuration when exposing via Ingress [Kubernetes]

In docs is mentioned, that Cloudflared can be used in a way that it points to Kubernetes Ingress, rather than Service.

What is the example ingress configuration of this?

There is example config for service, but nothing for ingress so far…

Should Cloudflared ingress be configured like this?

    - hostname: example.dev
      service: <ADDRESS of the k8s ingress>




I’m using Cloudflare with a nginx-ingress as well. Here my setup:

The ingress configuration is simple and has no difference to a “normal” ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
  name: your-nginx-ingress
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.class: "nginx"
    - hosts:
        - yourname.xyz
      secretName: yourname-xyz-tls
    - host: yourname.xzy
          - pathType: Prefix
            path: /(.*)
                name: your-service
                  number: 80

The only special thing here is that a letsencrypt ssl certificate is created for the given zone. This is only require if the SSL mode is set to “Full” for your zone in the Cloudflare Dashboard and recommended for security purposes. Otherwise it should work without.

I use CertManager to provide the SSL certificate. You can find the installation guide here. The cluster issuer (referenced at line 6 in the ingress ressource) looks like this:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
  name: letsencrypt-prod
  namespace: cert-manager
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
      name: letsencrypt-prod
      - dns01:
            email: <cloudflare account email>
              name: cloudflare-api-token-secret
              key: apiKey

The special thing here is that you need to configure a dns solver for the ACME verification process. CertManager offers a nice solution which works behind a Cloudflare proxied zone. The only thing you need is a Cloudflare API key with the permission to create dns records for the given zone. This key can be created in the Cloudflare dashboard. I recommend to store the key in k8s secret ressource:

apiVersion: v1
kind: Secret
  name: cloudflare-api-token-secret
  namespace: cert-manager
type: Opaque
  apiKey: <your cloudflare api key>

Thanks, but I was rather asking for cloudflared config.yaml configuration. Thanks :slight_smile:

EDIT: This one fixed too.

1 Like

also additonal question - do you use cloudflared deployment per namespace or you have figure it out somehow to keep it inside only one? :slight_smile:

EDIT: This one is fixed using nginx as load balancer and routing everything throught this balancer.

I think I might be able to answer what you’re asking.

I’ve set up cloudflared in a container running in the same namespace as my ingress, for cloudflared config I’ve set the following:

    # Autoupdates applied in a k8s pod will be lost when the pod is removed or restarted, so
    # autoupdate doesn't make sense in Kubernetes. However, outside of Kubernetes, we strongly
    # recommend using autoupdate.
    no-autoupdate: true
    # The `ingress` block tells cloudflared which local service to route incoming
    # requests to. For more about ingress rules, see
    # https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/ingress
    # Remember, these rules route traffic from cloudflared to a local service. To route traffic
    # from the internet to cloudflared, run `cloudflared tunnel route dns <tunnel> <hostname>`.
    # E.g. `cloudflared tunnel route dns example-tunnel tunnel.example.com`.
    # The first rule proxies traffic to the httpbin sample Service defined in app.yaml
    # This rule sends traffic to the built-in hello-world HTTP server. This can help debug connectivity
    # issues. If hello.example.com resolves and tunnel.example.com does not, then the problem is
    # in the connection from cloudflared to your local service, not from the internet to cloudflared.
    # This rule matches any traffic which didn't match a previous rule, and responds with HTTP 404.
    - service: http://p-gb-sys-kube-lddc01-ingress-nginx-controller:80

The last line is the important one - it means that all traffic (regardless of hostname) will be forwarded to the ingress Nginx service running on port 80 (from kubectl get svc)