Whitelisting allows you to control which users can see your website content based on their originating IP addresses. If the environment has whitelist enabled (and the IP is not on the list), the server will respond with a HTTP 403 “Forbidden”.
Examples when whitelist could be used:
- test site access needs to be restricted to a product team
- production site is behind a Web Application Firewall
Whitelists are enforced on the webserver (HTTP traffic on ports 80 and 443), so they cannot fully replace network-level security. Nevertheless, they are useful as an additional layer of access control in front of your application.
Silverstripe protects dynamic requests to sites in “test mode” via Basic Authentication by default. We strongly recommend IP whitelists as an additional protection measure, since the built-in authentication does not cover all requests to those environments.
Adding your IP to the whitelist
By default, all environments start with whitelist enabled (“deny all” mode), with the default of Silverstripe Operations to be permitted access.
The state of the whitelist will be visible in Cloud, on the “Whitelist” tab of your environment.
Add your IP to the list visible below, and press “Save”. You will receive a prompt asking you to deploy the changes, after which you will be able to access the website.
You can specify network CIDRs (e.g. 10.20.30.0/24) instead of IP addresses too.
Disabling whitelist
Disabling the whitelist (“allow all” mode) means your website will be publicly accessible from the internet regardless of originating IP. If the whitelist is disabled, Cloud will show:
Normally your production servers should have the whitelist disabled.
Note: disabling the whitelist will remove the whitelist altogether, the whitelist can not be recovered after it is disabled by re-enabling.
Specifying whitelists using .platform.yml
In addition to using the Cloud UI for enabling and disabling whitelists, you can specify a whitelist within your .platform.yml file which is applied on top of any whitelists already set within the UI. This allows you to maintain one whitelist across multiple environments, and ensuring the whitelist is under version control.
Three different whitelist types are supported within .platform.yml:
-
general- global whitelist affecting all URLs -
security- whitelist affecting /Security/* -
admin- whitelist affecting /admin/*
The whitelist format allows you to specify these whitelist types for your base stack (mysite) and any virtual stacks.
whitelist:
mysite:
general:
- "123.123.123.123"
- "123.255.123.255"
admin:
- "111.111.111.111"
- "255.255.255.255"
vstack1:
security:
- "1.0.0.1"
- "2.0.0.2"
- "1.2.3.0/22"
IP addresses can be defined as-is, or as CIDR ranges to cover a group of IP addresses. A full deployment is required to apply any changes to the whitelist.