Deprecation Notice: cloudflared-app is scheduled for archival in June 2024, and no further development or updates will occur.
Giant Swarm offers a Cloudflared App which can be installed in workload clusters. Here we define the Cloudflared chart with its templates and default configuration.
This app allows you to launch Cloudflare Tunnels and then route directly to services inside of your cluster. This approach bypasses any external ingress paths and can also be configured to bypass Kubernetes Ingress.
This approach makes it a lot easier for customers who might be constrained in regards to ingress options (such as limited external load balancer services or for security reasons). It is especially useful for clusters that are OnPrem and not running in a Public Cloud provider, as it allows those users to route traffic from a public interface (Cloudflare) to private services running in Kubernetes.
Anyone that has a Cloudflare account can use this App.
- Installing
- Configuring
- Testing
- Compatibility
- Limitations
- Release Process
- Contributing & Reporting Bugs
- Credit
There are 3 ways to install this app onto a workload cluster.
- Using our web interface
- Using our API
- Directly creating the App custom resource on the management cluster.
(Note: It is possible to use the chart in this repository directly)
This app can be used in 2 ways:
- Use existing tunnels -> This is the recommended Cloudflare way of running Cloudflared Tunnels
- App Managed -> The App manages to create and delete the tunnels for you
Create Cloudflared Tunnel(s) from an existing device (It is recommended to at least create two tunnels for resilience). You can run cloudflared
command:
$ cloudflared tunnel create <NAME>
It creates the tunnel and generates the credentials file in the default cloudflared directory. Also, it creates a subdomain of .cfargotunnel.com.
Note: You can map your (sub)domain now to the tunnel one <TUNNEL_ID>.cfargotunnel.com.
. More info in the official guide.
Once the tunnels are created, the credentials JSON file(s) can be found in ~/.cloudflared/
. These need to be saved in a Kubernetes secret:
kubectl create secret generic -n cloudflared-namespace cloudflared-credentials --from-file=credentials.json=~/.cloudflared/<TUNNEL_ID-1>.json
At the same time, it is required to set useExistingTunnels.enabled
to true and complete the keys within useExistingTunnels
(An example is presented below).
In order to use this you will need to ensure you have the following:
- Email address to login to Cloudflare API
- Cloudflare Account ID
- Cloudflare API token with
Account:MyAccount Tunnel:Edit
capability
The Tunnel requires a secret to launch, if one is not supplied the App can create one for you. But as this secret is essential for launching the tunnel it must be saved securely to ensure that you can launch the tunnel elsewhere if needed.
You can supply your own secret:
uuidgen | base64 | kubectl create secret -n my-tunnel generic my-tunnel-secret --from-file=/dev/stdin
The tunnel secret needs to be 32 bytes or more and needs to be stored base64 encoded. You can later supply the Kubernetes secret name.
####
Value | Description | Default |
---|---|---|
replicas |
Number of replicas to use for a deployment | 2 |
initImage.registry |
Registry used for the init container image | quay.io |
initImage.name |
Image name used for the init container | giantswarm/debug |
initImage.tag |
Tag of init container image | master |
initImage.pullPolicy |
Init container image Pull Policy | IfNotPresent |
image.registry |
Registry used for cloudflared | quay.io |
image.name |
Image name for cloudflared | giantswarm/cloudflared |
image.tag |
Tag used for cloudflared image | 2022.8.4-amd64 |
image.pullPolicy |
Pull policy for cloudflared image | IfNotPresent |
accountEmail |
Account Email to use for the API (required) | "" |
accountId |
Account ID (see above, required) | "" |
apiKey |
API key used for the API (see above, required or apiKeySecretName needs to be set) |
"" |
apiKeySecretName |
Name of existing secret that containers the API Key, the API key needs to be stored in a key in the secret called apiKey (required or apiKey needs to be set) |
"" |
tunnelSecretBase64 |
Base64 encoded Tunnel Secret (see below, required or tunnelSecretName needs to be set |
"" |
tunnelSecretName |
Name of existing secret container Tunnel Secret, the tunnel secret needs to be stored in a key in the secret called tunnelSecret (required or tunnelSecretBase64 needs to be set) |
"" |
config |
Config file used for cloudflared. See online documentation | see values.yaml |
useExistingTunnels.enabled |
Whether to use an existing Tunnel | false |
useExistingTunnels.credentialsSecretName |
Secret name that contains the credential files | "" |
useExistingTunnels.tunnel |
Either the tunnel name or tunnel ID as found in credentials file | "" |
# values.yaml
accountEmail: "xxxx@xxxxx.com"
accountId: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
apiKey: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
tunnelSecretBase64: "ZUY0xjNhZTgtNWI4MCx0ZjcvLTkxMOEt4zEyOWQyZDQpN8Y0Cg=="
config:
no-tls-verify: false
loglevel: "info"
transport-loglevel: "info"
ingress:
- hostname: echo.xxxxxx.com
service: http://echo-echo-server.default.svc.cluster.local
- service: http_status:404
useExistingTunnels:
enabled: true
credentialsSecretName: my-tunnel-credentials
tunnel: "f8c06a8a-1880-4e6e-8502-deb8f1d1253b"
config:
no-tls-verify: false
loglevel: "info"
transport-loglevel: "info"
ingress:
- hostname: echo.xxxxxxxxxx.com
service: http://echo-echo-server.default.svc.cluster.local
- service: http_status:404
Cloudflare offers the possibility of setting Quick Tunnels up for testing purposes.
Quick Tunnels do not require registration or credentials and they offer a random URL under the trycloudflare.com
domain. The URL is provided by the cloudflared application in its logs.
useQuickTunnel: true
config:
ingress:
- service: http://echo-echo-server.default.svc.cluster.local
This app has been tested to work with the following workload cluster release versions:
- KVM
v16.2.0
Some apps have restrictions on how they can be deployed. Not following these limitations will most likely result in a broken deployment.
- Ensure CHANGELOG.md is up to date.
- Create a new branch to trigger the release workflow e.g. to release
v0.1.0
, create a branch from main calledmain#release#v0.1.0
and push it. - This will push a new git tag and trigger a new tarball to be pushed to the
default-catalog
and thegiantswarm-catalog
If you have suggestions for how cloudflared
could be improved, or want to report a bug, open an issue! We'd love all and any contributions.
Check out the Contributing Guide for details on the contribution workflow, submitting patches, and reporting bugs.