Joseph Edmonds

Cloudflare Teams with Google Apps/Suite/Workplace

by Joseph Edmonds

by Joseph Edmonds

Cloudflare Teams provides an excellent alternative for VPN protections where you want to provide remote, work from home or even inside the office staff with controlled access to protected web apps, SASS platforms and even SSH.

The very generous free tier includes 50 users with basic logging functionality. You can pay extra for upgraded features such as longer log retention if those are worth it for you.

In this walk through, we’re going to hook it up with Google Workspace – (formerly Suite – (formerly Apps)) for single sign on

If you would like help getting your infrastructure protected by Cloudflare Teams – get in touch today!


  • Already have a Cloudflare account
  • You need to be using Google Workspace (Suite/Apps) if you want to use this for single sign on (SSO)
  • Only one level subdomains are supported (easily)

See official docs before you get started section.

Pre Tasks

Allow Google Workspace to Connect

Sign into Google workspace console and adjust security settings:

In the Google Admin console, navigate to Security > API controls.
Check the Trust internal, domain-owned apps option.

see cloudflare FAQ

Open up Port 7844 on Any Firewalls

If your servers are running firewalls and/or behind firewalls, then you need to make sure that port 7844 is open for outbound connections

Configure SSL in Cloudflare

You need to ensure SSL is set to “full” – you can try “full strict” but you might hit issues

Creating Group

Within Cloudflare teams, you can create “groups” which are then able to be assigned permissions.

To start with, its suggested that you make a general group for everyone with an email address at the Google workplace domain, so you will “require” emails ending in

See official docs on groups

Google Workplace Authentication

We want to allow users to authenticate using Google Workplace logins. Strongly suggest Google Workplace has 2FA required for all users.

Go to Settings->Authentication, scroll down to Login Methods and click Add New, then select Google Workplace.

You are required to configure a new app within Google Cloud Console. The process is well documented here

You need to generate an App ID and Client Secret. Your Google Workspace domain is simply the domain that you use for Google workplace emails, eg

Suggestion – Remove One Time Pin

Once you have enabled Google Workplace authentication, you should remove the One Time Pin login method – simply click Edit and then press the Delete button.

Creating Application Config

You need to add an application that will be protected. You can protect both self hosted and some SAAS apps. For this guide we will focus on self hosted apps.

When creating the app, you should create a single policy to allow users by using the “Assign a group” functionality and choosing the group you previously created.

See official docs on self hosted applications

Applications you create should default to using the Google Workplace authentication you previously created.

Installing Tunnel on Server

This depends on your particular server. Suggest you hit the official docs page on installing on Linux if you intend to do this by hand.

Install Binary

First you need to install the binary. There are apt and rpm packages available. In Ansible you might do something like:

    - name: Install Binary

Authorise Cloudflare

See official docs

Next you need to authenticate with Cloudflare, which is a step that needs you to have access to a logged in browser session on Cloudflare. You can run this step manually on the server or you could choose to do this step on a local machine and simply capture the created file so that you can push this to servers.

cloudflared tunnel login

This command will generate a URL which you can follow to authorise the request and once authorised it will create a cert file in ~/.cloudflared/cert.pem

Create Tunnel

See official docs

Again this is a step you can run manually on the server, or you can run locally and capture the generated files in order to deploy to a production server.

cloudflared tunnel create TUNNEL_NAME

This will create the tunnel and will also create a file in your ~/.cloudflared/ folder

The name of the file is the UUID of the tunnel and with a .json extension

Connecting Tunnel to Self Hosted Application

The tunnel running on the server does nothing until we configure cloudflared to actually use that tunnel to connect it to a specific application or entire network. For this guide, we’re focussing on connecting a specific application.

Create Config File

You need to create a config.yml file in your ~/.cloudflared

The file should reference the tunnel UUID you previously created, and look something like this:

tunnel: (uuid)
credentials-file: /root/.cloudflared/(uuid).json

Note, we will update this config file further once we are configuring our application.

Test Tunnel

Now you can test run the tunnel to confirm that it can connect properly

cloudflared --config ~/.cloudflared/config.yaml tunnel run

If this is all green, then you can go to the next step, but if you see some red errors then you need to debug.

Connection failures along the lines of:

Then you need to reconfirm that you have opened up all firewalls to allow outbound port 7844

Install Service

Once you have confirmed the tunnel can be started manually, you should install the service and enable it:

cloudflared service install
systemctl enable --now cloudflared
systemctl status cloudflared

Confirm the output of systemctl status does not show any errors.

Symlink Config

When creating the service, the config file in ~/.cloudflared/config.yml is actually copied to /etc/cloudflared/config.yml. If you are like me, this could confuse the hell out of you for quite some time as you continue to edit the file in it’s original location.

Easy solution here is to have one canonical config file and symlink the other one to it.

cd /etc/cloudflared
rm config.yml
ln -s /root/.cloudflared/config.yml
systemctl restart cloudflared
systemctl status cloudflared

Configuring Web Server for Tunnel Protection

We need to have a web server that is listening on whatever port we want. That server should be offering up SSL protection and if possible be running a valid SSL certificate (using letsencrypt is a good option). We need to configure cloudflared to support the service.

  • Web server with
    • SSL protection
    • IP restriction
  • Cloudflared config updated with ingress rules

Remove Domains from DNS

If you are trying to protect a subdomain/domain that is already in your cloudflare DNS, then you need to remove it as the tunnel config will create a new CNAME entry.

Create DNS CNAME for Domains

To actually route your protected domain via the tunnel so that it gets the Teams protection, we need to create a CNAME entry. This could be done manually, however the cloudflared tool makes this easy

cloudflared tunnel route dns (uuid)

cloudflared tunnel route dns (uuid)

Note (uuid) should be replaced with the uuid of the tunnel you created previously.

Configure Webserver

Configuring your webserver is up to you and depends on the specific web server software you have installed.

I would hope you already had valid SSL in place. If not, look into using letsencrypt to generate free valid SSL, or you can generate SSL certificates for your origin server within Cloudflare.

IP restriction is generally quite easy to do, but make sure you allow not only but also ::1.

You can choose to restrict all other traffic which then enforces that traffic comes through Cloudflare, or you could opt to allow a few other IPs – those IPs would then need to have custom DNS or hosts file entries to allow direct access.

Cloudflared Config

You need to update your cloudflared config with ingress rules and I’d suggest you do something that looks like this:

tunnel: (uuid)
credentials-file: /root/.cloudflared/(uuid).json
protocol: http2
loglevel: info
logfile: /var/log/cloudflared.log
    - hostname:
      service: https://localhost:443
        connectTimeout: 10s
        noTLSVerify: true

    - hostname:
      service: https://localhost:443
        connectTimeout: 10s
        noTLSVerify: true

    - service: http_status:404

This configure 2 services running on and This configuration allows you to keep your existing webserver configuration largely unchanged and you should only need to update IP restriction

This also configures a catchall 404 service which is required.

Once you have configured your webserver and cloudflared, make sure you restart both services and then try accessing the protected services via a browser – you should see the teams login page and that’s it, you are now protected.

Other Notes

Useful Articles/Searches

Tips – Cloudflare Teams is a relatively new name for things that have existed for a while.

Tunnels used to be Argo Tunnels and you will find lots more stuff if you search for Argo Tunnels.

Teams was previously called Cloudflare Access

this article for centmin is also quite useful

Installing WARP

WARP is the official Cloudflare Teams client software which can be installed on desktop and mobile devices. Warp is not required for Teams protection of self hosted apps. You may decide you want to use it though for other reasons.

See official install docs

For Fedora, I found that it was needed to do the following:

# Install repo
sudo rpm -ivh

# Hard code for Centos 8 as we are in Fedora
sudo echo '[cloudflare]
name=Cloudflare CentOS Packages
'> /etc/yum.repos.d/cloudflare.repo

# Install the cli tool
sudo dnf install cloudflare-warp

# Get warp running
sudo warp-cli register
sudo warp-cli connect

# Ensure this contains warp=on

# Connect to teams
sudo warp-cli teams-enroll

About Joseph Edmonds

About Joseph Edmonds

Personal musings, tech tips, trivia and other things that might be interesting.

Get in touch today

Send me a message concerning your idea, problem, or question – and I’ll personally respond as soon as possible.

Connect with me on LinkedIn.