About ACLs

Malicious actors can present themselves in a variety of ways on the internet. Automated tools can scrape information from your website, bots can probe your application for vulnerabilities, and hackers can exploit them. Using access control lists (ACLs) at the edge can help prevent the offending IP addresses they use from ever accessing your information resources.

When ACLs can be useful

Access control lists at the edge might be useful for:

• E-commerce companies preventing scraping from certain IP ranges.
• Offices restricting access to their administrative portals.
• Advertising technology companies blocking bad-actors at the edge.
• Mobile applications accepting only calls from specific proxies or IP ranges.
• System administrators restricting access to groups of backends from an office IP address or subnet range.

How ACLs work

ACLs have two parts: an ACL container and the ACL entries within it. In combination, containers and entries allow you to store a list of permissions used to grant or restrict access to URLs within your services.

Once you attach an ACL container to a version of your service and that service is activated, the data in the container (the ACL entries) becomes versionless. This means that once your service is activated, any further changes to the data within, such as the addition of ACL entries, will become effective immediately.

Ways to create ACLs

To create an ACL at the edge and use it within your service, start by creating an empty ACL container and then add its entries. You can create ACLs in several ways. For most configurations that integrate websites or applications with an ACL at the edge, you can:

• use the service configuration for CDN services.
• use the Fastly API for both CDN and Compute services.
• use the Resources tab for Compute services.
• use the Fastly CLI for Compute services

For simple access control requirements in which a few IP addresses can be hardcoded, you can manually create an ACL using VCL. Manually created ACLs are only supported for use with CDN services and are versioned, meaning any changes to the ACL will require changes to your VCL.

Limitations

When working with ACL containers and entries specifically, remember the following:

• ACL entry changes via the API don't appear in the event logs. If you use the API to add, update, or remove an ACL entry, there will be no record of it in the audit log or event log. The only record of a change will exist when you compare service versions and view the exact point at which the ACL was associated with the service version in the first place.
• ACL entry deletions are permanent. ACL entries are versionless. This means that if you delete an entry within an ACL container, that entry is permanently removed from all service versions and cannot be recovered.
• ACL containers are limited to 1000 ACL entries. If you find your containers approaching this entry limit, contact support. We may be able to help you figure out an even more efficient way to do things with your ACLs at the edge.