Cloudflare Access - CLI Auth Beta

Hi everyone! We are launching a new beta feature for Cloudflare Access today. Using the Cloudflare command line tool, Cloudflared, you will be able to reach an API that is protected by Access.

The feature relies on the same command line tool used to configure Argo Tunnel. Instructions on how to download use can be found here:
https://developers.cloudflare.com/access/connecting-to-apps/

We’re excited to listen to your feedback as we improve the tool! Please let us know what you think, good and bad.

  • Sam
6 Likes

Right now, the longest session duration that can be used for Access is one month. Do you have any plans to increase this? It would be nice if we didn’t have to rotate tokens every month.

Alternatively, could we have a Cloudflare UI for generating static tokens which expire much later, for long-term configuration?

Great feature nonetheless! Thanks for your work!

Hi Algirdas, thanks for trying it out. We’re working on supporting those types of service-to-service connections. This initial release is meant for an individual user interacting with an API manually. The service connections are coming soon though.

1 Like

Just a heads up - we’ll be rolling back this feature in Cloudflared while we address some feedback. We expect the capability to be added back on Monday.

1 Like

I followed the instructions here, but was able to login only by using Cloudflared access login https://example.com, not using the Cloudflared access token https://example.com as it says here:

https://developers.cloudflare.com/access/connecting-to-apps/connecting-from-cli/

Plus I was already logged in and it had issues seeing the token, I had to delete the cookies.

Hi Matteo - thanks for the feedback!

That’s correct - the token command only retrieves the token once you have logged in, it does not initiate the login process.

And good point on the issue being logged in. We list that as a known limitation in the docs today and are working to address it.

Sam

In the docs, maybe I misread them, but it seems like they ask you to begin by doing that. The error it gives is also not helpful.

Didn’t see that!

Thanks for that feedback; we’ll improve the error messaging.

1 Like

Nice work!

Might TLS client auth be incorporated?

We’re busy planning how to extend Access in more directions, mTLS included. Stay tuned!

1 Like

I’m using Cloudflared 2019.4 for integrating Cloudflare Access with an existing python application that sends requests to a web API. It’s working fine, but the developer experience is not ideal. I would really appreciate a json output option and the use of return codes for access login. Since now it always returns 0 and the only way for me to get the token is to parse the human-readable text by breaking it into lines, searching for the line that contains Successfully fetched your token: and then taking the next line.

I have a problem with the cloudflared access tcp command on Windows.

I configured a host (the internal server) according to the documentation for tunneling arbitrary tcp ports. Now I try to connect two clients — one is running Mac OS X and the other is running Windows 10:

  • The Mac OS X works great (although I had to install cloudflared by hand because the Homebrew one lacked the access tcp subcommand). I execute cloudflared access tcp --hostname [host] --url localhost:5432, a browser window with the SSO prompt opens, I log in, the connection works.
  • On Windows 10 the browser window never opens. I execute C:\cloudflared.exe access tcp --hostname [host] --url localhost:5432 and nothing happens. The command outputs INFO[0000] Start Websocket listener on: localhost:5432 and that’s it. There is no way to authenticate.

On Mac OS X I use cloudflared version 2020.4.0 (built 2020-04-14-1853 UTC), and on Windows it is 2020.4.0 (built 2020-04-14-1858 UTC). Both freshly installed.

Thanks for the report, Ludwik.

Could you try sending a request through that localhost port that you have created on the Windows machine to see if that triggers the auth prompt?

When I use RDP it requires a request through the tunnel for it to request auth.

Also, since when are random TCP ports allowed via Argo Tunnel?!

1 Like

I just tried this and got my hopes up, alas, it does do arbitrary ports but still only the SSH protocol. It would be really nice if tunnel could create and tunnel as a Spectrum application.

Edit: actually maybe it does, but I wasn’t able to get it working for my arbitrary TCP protocol for my mmo game. https://developers.cloudflare.com/access/other-protocols/tcp-guide/

Oh, really? I am sad :disappointed:

Thanks for trying though!

edit I’ll try then… will report back.

Think this might have been related, although I’m not sure.

Reporting back… here’s what I was able to do.
For reference, the domain I’m testing on does have Spectrum TCP, but it doesn’t look like that matters.

docker container i’m using:

"Environmental variables map[TUNNEL_HOSTNAME:a.example.com TUNNEL_URL:tcp://haproxy:7198]"
time="2020-04-27T01:40:40Z" level=info msg="Proxying tunnel requests to http://127.0.0.1:32841"
time="2020-04-27T01:40:40Z" level=info msg="Connected to ATL" connectionID=0

With this I see the tunnel in the network app and DNS app.

Now, on Windows:

.\cloudflared.exe access tcp --hostname a.example.com --url 127.0.0.1:7198
INFO[0000] Start Websocket listener on: 127.0.0.1:7198

Go to the URL in my browser (Access is on and protecting subdomain at this point):

A browser window should have opened at the following URL:

.../cdn-cgi/access/cli?...

If the browser failed to open, please visit the URL above directly in your browser.
ERRO[0019] failed to connect to https://a.example.com  error="websocket: bad handshake"

And, with that error, trying to connect via tcp to 127.0.0.1 (or a.example.com) doesn’t work.

Why is it saying proxying tunnel requests to http://127.0.0.1:32841? Shouldn’t it say at least TCP?

I don’t have TCP services (which don’t require UDP as well) running, I only have HTTP ones.

I would suspect that’s the HTTPS port that shows the "you’re authenticated with CF access " page. My TUNNEL_URL was tcp://haproxy:7198 so anything happening is probably the tool’s fault.