This adds a new optional check to `build_cloudflared` to require a git
tag if `ENSURE_TAG` is set.
This also adds a separate build named `build_cloudflared_tagged_release`
which is essentially a copy of the `build_cloudflared` build,
but adds ...
- a rule to only run on the `master` _branch
- secrets scoped only to that branch
- the `ENSURE_TAG` variable, to enable the new tag check
Using path package methods can cause errors on windows machines.
path methods are used for url operations and unix specific operation.
filepath methods are used for file system paths and its cross platform.
Remove strings.HasSuffix and use filepath.Ext and path.Ext for file and
url extenstions respectively.
## Issue
The [documentation for creating a tunnel's configuration
file](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/get-started/create-local-tunnel/#4-create-a-configuration-file)
does not specify that the `credentials-file` field in `config.yml` needs
to be an absolute path.
A user (E.G. me 🤦) might add a path like `~/.cloudflared/<uuid>.json`
and wonder why the `cloudflared tunnel run` command is throwing a
credentials file not found error. Although one might consider it
intuitive, it's not a fair assumption as a lot of CLI tools allow file
paths with `~` for specifying files.
P.S. The tunnel ID in the following snippet is not a real tunnel ID, I
just generated it.
```
url: http://localhost:8000
tunnel: 958a1ef6-ff8c-4455-825a-5aed91242135
credentials-file: ~/.cloudflared/958a1ef6-ff8c-4455-825a-5aed91242135.json
```
Furthermore, the error has a confusing message for the user as the file
at the logged path actually exists, it is just that `os.Stat` failed
because it could not expand the `~`.
## Solution
This commit fixes the above issue by running a `homedir.Expand` on the
`credentials-file` path in the `credentialFinder` function.
Per the contribution guidelines, this seemed to me like a small enough
change to not warrant an issue before creating this pull request. Let me
know if you'd like me to create one anyway.
## Background
While working with `cloudflared` on FreeBSD recently, I noticed that
there's an inconsistency with the available CLI commands on that OS
versus others — namely that the `service` command doesn't exist at all
for operating systems other than Linux, macOS, and Windows.
Contrast `cloudflared --help` output on macOS versus FreeBSD (truncated
to focus on the `COMMANDS` section):
- Current help output on macOS:
```text
COMMANDS:
update Update the agent if a new version exists
version Print the version
proxy-dns Run a DNS over HTTPS proxy server.
tail Stream logs from a remote cloudflared
service Manages the cloudflared launch agent
help, h Shows a list of commands or help for one command
Access:
access, forward access <subcommand>
Tunnel:
tunnel Use Cloudflare Tunnel to expose private services to the Internet
or to Cloudflare connected private users.
```
- Current help output on FreeBSD:
```text
COMMANDS:
update Update the agent if a new version exists
version Print the version
proxy-dns Run a DNS over HTTPS proxy server.
tail Stream logs from a remote cloudflared
help, h Shows a list of commands or help for one command
Access:
access, forward access <subcommand>
Tunnel:
tunnel Use Cloudflare Tunnel to expose private services to the Internet
or to Cloudflare connected private users.
```
This omission has caused confusion for users (including me), especially
since the provided command in the Cloudflare Zero Trust dashboard
returns a seemingly-unrelated error message:
```console
$ sudo cloudflared service install ...
You did not specify any valid additional argument to the cloudflared tunnel command.
If you are trying to run a Quick Tunnel then you need to explicitly pass the --url flag.
Eg. cloudflared tunnel --url localhost:8080/.
Please note that Quick Tunnels are meant to be ephemeral and should only be used for testing purposes.
For production usage, we recommend creating Named Tunnels. (https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/install-and-setup/tunnel-guide/)
```
## Contribution
This pull request adds a "stub" `service` command (including the usual
subcommands available on other OSes) to explicitly declare it as
unsupported on the operating system.
New help output on FreeBSD (and other operating systems where service
management is unsupported):
```text
COMMANDS:
update Update the agent if a new version exists
version Print the version
proxy-dns Run a DNS over HTTPS proxy server.
tail Stream logs from a remote cloudflared
service Manages the cloudflared system service (not supported on this operating system)
help, h Shows a list of commands or help for one command
Access:
access, forward access <subcommand>
Tunnel:
tunnel Use Cloudflare Tunnel to expose private services to the Internet or to Cloudflare connected private users.
```
New outputs when running the service management subcommands:
```console
$ sudo cloudflared service install ...
service installation is not supported on this operating system
```
```console
$ sudo cloudflared service uninstall ...
service uninstallation is not supported on this operating system
```
This keeps the available commands consistent until proper service
management support can be added for these otherwise-supported operating
systems.
## Summary
This change ensures that errors resulting from the `cloudflared access ssh` call are no longer ignored. By returning the error from `carrier.StartClient` to the upstream, we ensure that these errors are properly logged on stdout, providing better visibility and debugging capabilities.
Relates to TUN-9101
## Summary
Within the work of FEDRamp it is necessary to change the HA SD lookup to use as srv `fed-v2-origintunneld`
This work assumes that the tunnel token has an optional endpoint field which will be used to modify the behaviour of the HA SD lookup.
Finally, the presence of the endpoint will override region to _fed_ and fail if any value is passed for the flag region.
Closes TUN-9007
## Summary
Within the scope of the FEDRamp High RM, it is necessary to detect if an user should connect to a FEDRamp colo.
At first, it was considered to add the --fedramp as global flag however this could be a footgun for the user or even an hindrance, thus, the proposal is to save in the token (during login) if the user authenticated using the FEDRamp Dashboard. This solution makes it easier to the user as they will only be required to pass the flag in login and nothing else.
* Introduces the new field, endpoint, in OriginCert
* Refactors login to remove the private key and certificate which are no longer used
* Login will only store the Argo Tunnel Token
* Remove namedTunnelToken as it was only used to for serialization
Closes TUN-8960
## Summary
This commit refactors some of the flags of cloudflared to their own module, so that they can be used across the code without requiring to literal strings which are much more error prone.
Closes TUN-8914
## Summary
This commit introduces a new command line flag, `--max-active-flows`, which allows overriding the remote configuration for the maximum number of active flows.
The flag can be used with the `run` command, like `cloudflared tunnel --no-autoupdate run --token <TUNNEL_TOKEN> --max-active-flows 50000`, or set via an environment variable `TUNNEL_MAX_ACTIVE_FLOWS`.
Note that locally-set values always take precedence over remote settings, even if the tunnel is remotely managed.
Closes TUN-8914
## Summary
When the FIPS compliance was achieved with HTTP/2 Transport the technology at the time wasn't available or certified to be used in tandem with Post-Quantum encryption. Nowadays, that is possible, thus, we can also remove this restriction from Cloudflared.
Closes TUN-8857
## Summary
Nowadays, Cloudflared only supports X25519Kyber768Draft00 (0x6399,25497) but older versions may use different preferences.
For FIPS compliance we are required to use P256Kyber768Draft00 (0xfe32,65074) which is supported in our internal fork of [Go-Boring-1.22.10](https://bitbucket.cfdata.org/projects/PLAT/repos/goboring/browse?at=refs/heads/go-boring/1.22.10 "Follow link").
In the near future, Go will support by default the X25519MLKEM768 (0x11ec,4588) given this we may drop the usage of our public fork of GO.
To summarise:
* Cloudflared FIPS: QUIC_CURVE_PREFERENCES=65074
* Cloudflared non-FIPS: QUIC_CURVE_PREFERENCES=4588
Closes TUN-8855
## Summary
This commit renames the public variable that identifies the metadata key and value for the ConnectResponse structure when the flow was rate limited.
Closes TUN-8904
## Summary
cloudflared access login and cloudflared access curl fails when the Access application has warp_as_auth enabled.
This bug originates from a 4 year old inconsistency where tokens signed by the nginx-fl-access module include 'aud' as a string, while tokens signed by the access authentication worker include 'aud' as an array of strings.
When the new(ish) feature warp_as_auth is enabled for the app, the fl module signs the token as opposed to the worker like usually.
I'm going to bring this up to the Access team, and try to figure out a way to consolidate this discrepancy without breaking behaviour.
Meanwhile we have this [CUSTESC ](https://jira.cfdata.org/browse/CUSTESC-47987), so I'm making cloudflared more lenient by accepting both []string and string in the token 'aud' field.
Tested this by compiling and running cloudflared access curls to my domains
Closes AUTH-6633
GoncaloGarcia
Larry Archer
Tom Lianza
João "Pisco" Fernandes
Cyb3r Jak3
gofastasf
Rohan Mukherjee
Shereef Marzouk
Bernhard M. Wiedemann
teslaedison
Micah Yeager
Roman
VFLC
Chung-Ting Huang
lneto
Jingqi Huang
Bas Westerbaan
Eduardo Gomes