Access New feature - Unified Application Definition and Reusable Policies

I am excited to announce a major update coming to Access Applications and Policies!

Cloudflare Access Self-Hosted Applications can now be defined by Private IPs, Private Hostnames (on port 443) and Public Hostnames. Additionally, we made Access Policies into their own object which allows reusing across multiple applications. These updates involved significant updates to the overall Access Dashboard experience. I have provided an overview of those updates below. For more information, the developer documentation has been updated to reflect the new features: Secure a private IP or hostname · Cloudflare Zero Trust docs

We are in the process of rolling out these updates. These updates will be rolled out over the next few weeks. We will be enabling for subsets of our Free and Pay as you Go customers. If you are an Enterprise customer interested in beta testing, please comment below or reach out to your account team and we can discuss options.

The four major changes include:

Access applications support private IPs and hostname definitions

Caveats:
Private hostnames are currently only available over port 443 over HTTPS. In the future, we will expand to arbitrary hostname support
Private IPs and Hostnames must be reachable over WARP, Magic WAN or Browser Isolation
Gateway TLS decryption must be enabled if you would like to present a login page via the browser. Otherwise, users will receive a pop-up notification from the WARP Client.

Access policies are now reusable

Previously, Access policies were always scoped to a specific application. This meant that you had to define a distinct policy for every single application.

As part of the migration to reusable Access policies, all existing Access policies will remain as a “legacy” policy that is still scoped to an application. “Legacy” will show up in the new Policies tab as read-only.

How do I migrate to reusable policies?
Via UI: We recommend creating a reusable policy or set of policies and assigning those to the desired applications. Once a reusable policy has been assigned, the legacy policy can be deleted by opening the specific application and removing the policy directly.

Via API:
The above recommendation can be done in the API or Terraform. The API allows one additional option to convert a legacy policy to a reusable policy.

Use the following endpoint with a PUT: https://api.cloudflare.com/client/v4/$ACCOUNT_ID/access/apps/{appID}/policies/{legacy_policy_id}/make_reusable

The request body should be empty

This will convert any legacy policy into a reusable policy that can then be assigned to multiple applications. Once converted, the policy can only be edited through the reusable policies endpoints (i.e. you can no longer edit the policy through: PUT /apps/id/policies/id )

Access Groups are now Rule Groups

We renamed Access Groups to Rule Groups. We made this change based on feedback that Access Groups were easily mixed up with identity provider groups.

Additionally, Rule Groups were moved back to be a policy selector instead of their own section in the policy builder. We made this change because of feedback that it was often difficult to decipher how a policy would behave with both Rules Groups and specific policy clauses.

Added a Private Apps selector to Gateway

By default, Gateway will evaluate Access private applications at the end of the Network firewall.
If you would like Access private applications to be evaluated before or after specific Gateway network policies, you can add the All Access Private Apps selector with an Allow policy.

Note: All Access private applications are deny by default and a user must pass the associated Access policy. The Gateway policy is strictly for routing and connectivity purposes.

What’s happening to the existing Private Network application type?

This application type will eventually be deprecated in favor of private IP and Hostname support in Self Hosted Applications. We will communicate all deprecation dates but have not set a timeline. The initial deprecation will block creation of all new Private Network applications, while all existing private network applications will continue to be editable.

Feedback / Something’s broken

While we are very excited about these changes and have tested heavily, we know that upgrades can have unintended consequences. If you experience issues or have feedback to improve these new experiences, please share them on this community thread or, if you are an Enterprise customer, you can reach out to your account team.

-The Cloudflare Team

3 Likes

Hey Kenny, awesome changes to Access, many thanks to you and the team for continuous improvements.

I have one question - how does the new capability to publish applications using private hostnames relate to local domain fallback and private / internal DNS resolvers in an enterprise environment?

While those can be neatly defined within WARP configuration profiles, I’m unsure how that would work for RBI or Magic WAN. I guess running WARP is necessary for this to work and wouldn’t work with agentless RBI?

You can reply via email if you prefer.

Best regards,
Nikola

1 Like

Hey Nikola!

So clientless BISO will work because it also respects resolver policies. Follow this guide to configure it: Access to private apps without having to deploy client agents · Cloudflare Reference Architecture docs

Here’ an example of my own app working :smiley:

Only caveat is BISO is a bit limited in the MFA methods allowed (fido2 isn’t supported in BISO yet, but we have some early access stuff you can try out in tandem with this).

2 Likes

This has now been rolled out to all customers across all plans! Let us know if you encounter any issues.

Thanks for the updates! I have an issue with Legacy Policies and the new Infrastructure Apps:
When creating Infrastructure Apps via the GUI, they default to a legacy policy with limited restrictions. After creation, you can manually edit the policy to add more (like IP restrictions), which feels like a bug.

The API doesn’t support updating these legacy policies, and they can’t be fully removed from Infrastructure Apps. Should a different API be used? Also, shouldn’t Infrastructure Apps default to using reusable policies instead?

Main point: legacy policies can’t be updated via API but are still required for Infrastructure Apps—unless I’m missing something?

Thank you!

Hi Seth, legacy policies can be updated using the legacy apps//policies/ endpoint as in Cloudflare API | Zero Trust › Access › Applications › Policies › Update An Access Application Policy

Let me know if that doesnt work for you!

@egomes Thank you for your reply. Converting legacy policies for self-hosted apps is fine via the API. Zero issues there.

I’m saying that for the new “Infrastructure Apps” it requires a legacy policy. Try creating one in the GUI, it creates legacy policies that are not upgradeable to reusable ones, nor can you assign reusable policies to the Infrastructure app.

Hi Seth, my comment is only regarding this:

legacy policies can’t be updated via API

Legacy access policies can be updated in the API through the app-scoped (legacy) endpoint I’ve mentioned. Note that here I’m not talking about upgrading, but rather just normal policy PUT requests.

You’re right in that Infrastructure Apps do not yet support reusable policies, and subsequently any policies referenced by one of these apps are not upgradable.

Let me know if you have any questions

@egomes Thank you for your reply and clarification. That was actually my issue initially: I cannot update a legacy policy via API anymore thus my whole purpose of coming here and converting to reusable (my automations stopped work when this was changed and are now working again after my updates to use reusable (for self-hosted apps only, infrastructure ones are a work in progress on my side)).

In the docs you linked I no longer see that Legacy Policies have the “include” as a body parameter, but do show in the new reusable ones. Also some discrepancies in the docs for the path.

Main issue based on latest info: “include” is no longer a body parameter for updating legacy policies.

Wrong path mention for reusable and missing “include” body parameter:

Please let me know if you are seeing the same.
Thank you!

This must have been a temp outage or isolated issue:
I just retested using the old data, endpoints, etc, and it works just fine now. However, am curious on the documentation mentioned (also noted errors).

Positive note: Updated my automations to work with reusable policies :smile:

Any idea when reusable policies will come to Infrastructure Apps?

Thanks all!

Gremlins! :sweat_smile: Glad it’s working now.

We’re hoping to get Infra Apps onto reusable policies by the end of the summer. It’s a little bit tricky since infra apps have a target as part of the policy definition. It’s definitely our goal to unify!

I hope things have worked well with Infra Apps. The Bastion Zero team, who joined Cloudflare last year, has been hard at work on them. :slight_smile:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.