You can read Part 2 of Getting Started with Terraform here.
As a Product Manager at Cloudflare, I spend quite a bit of my time talking to customers. One of the most common topics I'm asked about is configuration management. Developers want to know how they can write code to manage their Cloudflare config, without interacting with our APIs or UI directly.
Following best practices in software development, they want to store configuration in their own source code repository (be it GitHub or otherwise), institute a change management process that includes code review, and be able to track their configuration versions and history over time. Additionally, they want the ability to quickly and easily roll back changes when required.
When I first spoke with our engineering teams about these requirements, they gave me the best answer a Product Manager could hope to hear: there's already an open source tool out there that does all of that (and more), with a strong community and plugin system to boot—it's called Terraform.
This blog post is about getting started using Terraform with Cloudflare and the new version 1.0 of our Terraform provider. A "provider" is simply a plugin that knows how to talk to a specific set of APIs—in this case, Cloudflare, but there are also providers available for AWS, Azure, Google Cloud, Kubernetes, VMware, and many more services. Today's release extends our existing provider that previously only supported DNS records with support for Zone Settings, Rate Limiting, Load Balancing, and Page Rules.
Before and after Terraform
Before we jump into some real-world examples of using Terraform with Cloudflare, here is a set of diagrams that depicts the paradigm shift.
Before Terraform, you needed to learn how to use the configuration interfaces or APIs of each cloud and edge provider, e.g., Google Cloud and Cloudflare below. Additionally, your ability to store your configuration in your own source code control system depends on vendor-specific configuration export mechanisms (which may or may not exist).
With Terraform, you can store and version your configuration in GitHub (or your source code control system of choice). Once you learn Terraform's configuration syntax, you don't need to bother learning how to use providers' UIs or APIs—you just tell Terraform what you want and it figures out the rest.
Installing Terraform
The installation process for Terraform is extremely simple as it ships as a single binary file. Official instructions for installing Terraform can be found here, and for purposes of this example we'll show to do so on a macOS using Homebrew:
$ brew install terraform
==> Downloading https://homebrew.bintray.com/bottles/terraform-0.11.7.sierra.bottle.tar.gz
######################################################################## 100.0%
==> Pouring terraform-0.11.7.sierra.bottle.tar.gz
? /usr/local/Cellar/terraform/0.11.7: 6 files, 80.2MB
$ terraform version
Terraform v0.11.7The following instructions are adapted from the Cloudflare Developers - Terraform documentation site, which includes a full tutorial and coverage of advanced topics.
If you're interested in seeing how to use a specific Terraform resource or technique, click on one of the following anchor links:
Load Balancing Resource (next post!)
Page Rules Resource (next post!)
Reviewing and Rolling Back Configuration (next post!)
Importing Existing State and Configuration (next post!)
Hello, world!
Now that Terraform is installed, it's time to start using it. Let's assume you have a web server for your domain that's accessible on 203.0.113.10. You just signed up your domain, example.com, on Cloudflare and want to manage everything with Terraform.
1. Define your first Terraform config file
First we'll create a initial Terraform config file. Any files ending in .tf will be processed by Terraform. As you configuration gets more complex you'll want to split the config into separate files and modules, but for now we'll proceed with a single file:
$ cat > cloudflare.tf <<'EOF'
provider "cloudflare" {
email = "you@example.com"
token = "your-api-key"
}
variable "domain" {
default = "example.com"
}
resource "cloudflare_record" "www" {
domain = "${var.domain}"
name = "www"
value = "203.0.113.10"
type = "A"
proxied = true
}
EOF2. Initialize Terraform and the Cloudflare provider
Now that you've created your basic configuration in HCL let's initialize Terraform and ask it to apply the configuration to Cloudflare. HCL stands for HashiCorp Configuration Lanaguage, and is named after the maker of Terraform.
$ terraform init
Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "cloudflare" (1.0.0)...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.cloudflare: version = "~> 1.0"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
When you run terraform init, any plugins required, such as the Cloudflare Terraform provider, are automatically downloaded and saved locally to a .terraform directory:
$ find .terraform/
.terraform/
.terraform//plugins
.terraform//plugins/darwin_amd64
.terraform//plugins/darwin_amd64/lock.json
.terraform//plugins/darwin_amd64/terraform-provider-cloudflare_v1.0.0_x43. Review the execution plan
With the Cloudflare provider installed, let's ask Terraform to show the changes it's planning to make to your Cloudflare account so you can confirm it matches the configuration you intended:
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
+ cloudflare_record.www
id: <computed>
created_on: <computed>
domain: "example.com"
hostname: <computed>
metadata.%: <computed>
modified_on: <computed>
name: "www"
proxiable: <computed>
proxied: "true"
ttl: <computed>
type: "A"
value: "203.0.113.10"
zone_id: <computed>
Plan: 1 to add, 0 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.As you can see in the above "execution plan”, Terraform is going to create a new DNS record, as requested. Values that you've explicitly specified are displayed, e.g., the value of the A record—203.0.113.10—while values that are derived based on other API calls, e.g., looking up the zone_id, or returned after the object is created, are displayed as <computed>.
4. Applying Your Changes
The plan command is important, as it allows you to preview the changes for accuracy before actually making them. Once you're comfortable with the execution plan, it's time to apply it:
$ terraform apply --auto-approve
cloudflare_record.www: Creating...
created_on: "" => "<computed>"
domain: "" => "example.com"
hostname: "" => "<computed>"
metadata.%: "" => "<computed>"
modified_on: "" => "<computed>"
name: "" => "www"
proxiable: "" => "<computed>"
proxied: "" => "true"
ttl: "" => "<computed>"
type: "" => "A"
value: "" => "203.0.113.10"
zone_id: "" => "<computed>"
cloudflare_record.www: Creation complete after 1s (ID: c38d3103767284e7cd14d5dad3ab8668)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Note that I specified –auto-approve on the command line for briefer output; without this flag, Terraform will show you the output of terraform plan and then ask for confirmation before applying it.
Verify the results
Logging back into the Cloudflare Dashboard and selecting the DNS tab, I can see the record that was created by Terraform:
If you'd like to see the full results returned from the API call (including the default values that you didn't specify but let Terraform compute), you can run terraform show:
$ terraform show
cloudflare_record.www:
id = c38d3103767284e7cd14d5dad3ab8668
created_on = 2018-04-08T00:37:33.76321Z
data.% = 0
domain = example.com
hostname = www.example.com
metadata.% = 2
metadata.auto_added = false
metadata.managed_by_apps = false
modified_on = 2018-04-08T00:37:33.76321Z
name = www
priority = 0
proxiable = true
proxied = true
ttl = 1
type = A
value = 203.0.113.10
zone_id = e2e6391340be87a3726f91fc4148b122$ curl https://www.example.com
Hello, this is 203.0.113.10!Tracking change history
In the terraform apply step above, you created and applied some basic Cloudflare configuration. Terraform was able to apply this configuration to your account because you provided your email address and API token at the top of the cloudflare.tf file:
$ head -n4 cloudflare.tf
provider "cloudflare" {
email = "you@example.com"
token = "your-api-key"
}We're now going to store your configuration in GitHub where it can be tracked, peer-reviewed, and rolled back to as needed. But before we do so, we're going to remove your credentials from the Terraform config file so it doesn't get committed to a repository.
1. Use environment variables for authentication
As a good security practice we need to remove your Cloudflare credentials from anything that will be committed to a repository. The Cloudflare Terraform provider supports reading these values from the CLOUDFLARE_EMAIL and CLOUDFLARE_TOKEN environment variables, so all we need to do is:
$ sed -ie 's/^.*email =.*$/ # email pulled from $CLOUDFLARE_EMAIL/' cloudflare.tf
$ sed -ie 's/^.*token =.*$/ # token pulled from $CLOUDFLARE_TOKEN/' cloudflare.tf
$ head -n4 cloudflare.tf
provider "cloudflare" {
# email pulled from $CLOUDFLARE_EMAIL
# token pulled from $CLOUDFLARE_TOKEN
}
$ export CLOUDFLARE_EMAIL=you@example.com
$ export CLOUDFLARE_TOKEN=your-api-keyNote that you need to leave the empty provider definition in the file, so that Terraform knows to install the Cloudflare plugin.
After completing the above step, it's a good idea to make sure that you can still authenticate to Cloudflare. By running terraform plan we can get Terraform to pull the current state (which requires a valid email and API key):
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
cloudflare_record.www: Refreshing state... (ID: c38d3102767284e7ca14d5dad3ab8b69)
------------------------------------------------------------------------
No changes. Infrastructure is up-to-date.
This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.Store your configuration in GitHubNow that credentials have been removed, it's time to initialize a git repository with your Cloudflare configuration and then push it to GitHub.
First we'll create the GitHub repository to store the config. This can be done via the GitHub UI or with a simple API call:
$ export GITHUB_USER=your-github-user
$ export GITHUB_TOKEN=your-github-token
$ export GITHUB_URL=$(curl -sSXPOST https://api.github.com/user/repos?access_token=$GITHUB_TOKEN -H 'Content-Type: application/json' \
-d '{"name": "cf-config", "private":"true"}' 2>/dev/null | jq -r .ssh_url)
$ echo $GITHUB_URL
git@github.com:$GITHUB_USER/cf-config.gitNow we'll initialize a git repository and make our first commit:
$ git init
Initialized empty Git repository in $HOME/cf-config/.git/
$ git remote add origin $GITHUB_URL
$ git add cloudflare.tf
$ git commit -m "Step 2 - Initial commit with webserver definition."
[master (root-commit) 5acea17] Step 2 - Initial commit with webserver definition.
1 file changed, 16 insertions(+)
create mode 100644 cloudflare.tfAn astute reader may have noticed that we did not commit the .terraform directory nor did we commit the terraform.tfstate file. The former was not committed because this repository may be used on a different architecture, and the plugins contained in this directory are built for the system on which terraform init was run. The latter was not committed as i) it may eventually contain sensitive strings and ii) it is not a good way to keep state in sync, as HashiCorp [explains].
To prevent git from bugging us about these files, let's add them to a new .gitignore file, commit it, and push everything to GitHub:
$ cat > .gitignore <<'EOF'
.terraform/
terraform.tfstate*
EOF
$ git add .gitignore
$ git commit -m "Step 2 - Ignore terraform plugin directory and state file."
[master 494c6d6] Step 2 - Ignore terraform plugin directory and state file.
1 file changed, 2 insertions(+)
create mode 100644 .gitignore
$ git push
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 762 bytes | 0 bytes/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To git@github.com:$GITHUB_USER/cf-config.git
* [new branch] master -> masterApplying zone settings
Now that you've got a basic website proxied through Cloudflare, it's time to use Terraform to adjust some additional settings on your zone. Below we'll configure some optional HTTPS settings, and then push the updated configuration to GitHub for posterity.
We'll use a new git branch for the changes, and then merge it into master before applying. On a team, you might consider using this step as an opportunity for others to review your change before merging and deploying it. Or you may integrate Terraform into your CI/CD system to perform tests automatically using another Cloudflare domain.
1. Create a new branch and append the new zone settings
Here, we modify the Terraform configuration to enable the following settings: TLS 1.3, Always Use HTTPS, Strict SSL mode, and the Cloudflare WAF. Strict mode requires a valid SSL certificate on your origin, so be sure to use the Cloudflare Origin CA to generate one.
$ git checkout -b step3-https
Switched to a new branch 'step3-https'
$ cat >> cloudflare.tf <<'EOF'
resource "cloudflare_zone_settings_override" "example-com-settings" {
name = "${var.domain}"
settings {
tls_1_3 = "on"
automatic_https_rewrites = "on"
ssl = "strict"
waf = "on"
}
}
EOF2. Preview and merge the changes
Let's take a look at what Terraform is proposing before we apply it. We filter the terraform plan output to ignore those values that will be "computed”—in this case, settings that will be left at their default values. For brevity from here on out, we'll omit some extranneous Terraform output; if you'd like to see the output exactly as run, please see the full tutorial.
$ terraform plan | grep -v "<computed>"
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
cloudflare_record.www: Refreshing state... (ID: c38d3103767284e7cd14d5dad3ab8668)
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
+ cloudflare_zone_settings_override.example-com-settings
name: "example.com"
settings.#: "1"
settings.0.automatic_https_rewrites: "on"
settings.0.ssl: "strict"
settings.0.tls_1_3: "on"
settings.0.waf: "on"
Plan: 1 to add, 0 to change, 0 to destroy.The proposed changes look good, so we'll merge them into primary and then apply them with terraform apply. When working on a team, you may want to require pull requests and use this opportunity to peer review any proposed configuration changes.
$ git add cloudflare.tf
$ git commit -m "Step 3 - Enable TLS 1.3, Always Use HTTPS, and SSL Strict mode."
[step3-https d540600] Step 3 - Enable TLS 1.3, Always Use HTTPS, and SSL Strict mode.
1 file changed, 11 insertions(+)
$ git checkout master
Switched to branch 'master'
$ git merge step3-https
Updating d26f40b..d540600
Fast-forward
cloudflare.tf | 11 +++++++++++
1 file changed, 11 insertions(+)
$ git push
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 501 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To git@github.com:$GITHUB_USER/cf-config.git
d26f40b..d540600 master -> master3. Apply and verify the changes
Before applying the changes, let's see if we can connect with TLS 1.3. Hint: we should not be able to with default settings. If you want to follow along with this test, you'll need to [compile curl against BoringSSL].
$ curl -v --tlsv1.3 https://www.upinatoms.com 2>&1 | grep "SSL connection\|error"
* error:1000042e:SSL routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSION
curl: (35) error:1000042e:SSL routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSIONAs shown above, we receive an error as TLS 1.3 is not yet enabled on your zone. Let's enable it by running terraform apply and try again:
$ terraform apply --auto-approve
cloudflare_record.www: Refreshing state... (ID: c38d3103767284e7cd14d5dad3ab8668)
cloudflare_zone_settings_override.example-com-settings: Creating...
initial_settings.#: "" => "<computed>"
initial_settings_read_at: "" => "<computed>"
name: "" => "example.com"
readonly_settings.#: "" => "<computed>"
settings.#: "" => "1"
settings.0.advanced_ddos: "" => "<computed>"
settings.0.always_online: "" => "<computed>"
settings.0.always_use_https: "" => "<computed>"
settings.0.automatic_https_rewrites: "" => "on"
settings.0.brotli: "" => "<computed>"
settings.0.browser_cache_ttl: "" => "<computed>"
settings.0.browser_check: "" => "<computed>"
settings.0.cache_level: "" => "<computed>"
settings.0.challenge_ttl: "" => "<computed>"
settings.0.cname_flattening: "" => "<computed>"
settings.0.development_mode: "" => "<computed>"
settings.0.edge_cache_ttl: "" => "<computed>"
settings.0.email_obfuscation: "" => "<computed>"
settings.0.hotlink_protection: "" => "<computed>"
settings.0.http2: "" => "<computed>"
settings.0.ip_geolocation: "" => "<computed>"
settings.0.ipv6: "" => "<computed>"
settings.0.max_upload: "" => "<computed>"
settings.0.minify.#: "" => "<computed>"
settings.0.mirage: "" => "<computed>"
settings.0.mobile_redirect.#: "" => "<computed>"
settings.0.opportunistic_encryption: "" => "<computed>"
settings.0.origin_error_page_pass_thru: "" => "<computed>"
settings.0.polish: "" => "<computed>"
settings.0.prefetch_preload: "" => "<computed>"
settings.0.privacy_pass: "" => "<computed>"
settings.0.pseudo_ipv4: "" => "<computed>"
settings.0.response_buffering: "" => "<computed>"
settings.0.rocket_loader: "" => "<computed>"
settings.0.security_header.#: "" => "<computed>"
settings.0.security_level: "" => "<computed>"
settings.0.server_side_exclude: "" => "<computed>"
settings.0.sha1_support: "" => "<computed>"
settings.0.sort_query_string_for_cache: "" => "<computed>"
settings.0.ssl: "" => "strict"
settings.0.tls_1_2_only: "" => "<computed>"
settings.0.tls_1_3: "" => "on"
settings.0.tls_client_auth: "" => "<computed>"
settings.0.true_client_ip_header: "" => "<computed>"
settings.0.waf: "" => "on"
settings.0.webp: "" => "<computed>"
settings.0.websockets: "" => "<computed>"
zone_status: "" => "<computed>"
zone_type: "" => "<computed>"
cloudflare_zone_settings_override.example-com-settings: Creation complete after 2s (ID: e2e6491340be87a3726f91fc4148b125)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.Now we can try the same command as above, and see that it succeeds. Niiice, TLS 1.3!
$ curl -v --tlsv1.3 https://www.example.com 2>&1 | grep "SSL connection\|error"
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256Managing rate limits
Before proceeding, make sure that your account is enabled for Rate Limiting. If you’re on an Enterprise plan, you should ask your Customer Success Manager to do this; otherwise, you can subscribe to Rate Limiting within the Cloudflare Dashboard.
With our zone settings locked down, and our site starting to get some more attention, it's unfortunately begun attracting some of the less scrupulous characters on the internet. Our server access logs show attempts to brute force our login page at https://www.example.com/login. Let's see what we can do with Cloudflare's rate limiting product) to put a stop to these efforts.
1. Create a new branch and append the rate limiting settings
After creating a new branch we specify the rate limiting rule:
$ git checkout -b step4-ratelimit
Switched to a new branch 'step4-ratelimit'
$ cat >> cloudflare.cf <<'EOF'
resource "cloudflare_rate_limit" "login-limit" {
zone = "${var.domain}"
threshold = 5
period = 60
match {
request {
url_pattern = "${var.domain}/login"
schemes = ["HTTP", "HTTPS"]
methods = ["POST"]
}
response {
statuses = [401, 403]
origin_traffic = true
}
}
action {
mode = "simulate"
timeout = 300
response {
content_type = "text/plain"
body = "You have failed to login 5 times in a 60 second period and will be blocked from attempting to login again for the next 5 minutes."
}
}
disabled = false
description = "Block failed login attempts (5 in 1 min) for 5 minutes."
}
EOFThis rule is a bit more complex than the zone settings rule, so let's break it down:
00: resource "cloudflare_rate_limit" "login-limit" {
01: zone = "${var.domain}"
02:
03: threshold = 5
04: period = 60The threshold is an integer count of how many times an event (defined by the match block below) has to be detected in the period before the rule takes action. The period is measured in seconds, so the above rule says to take action if the match fires 5 times in 60 seconds.
05: match {
06: request {
07: url_pattern = "${var.domain}/login"
08: schemes = ["HTTP", "HTTPS"]
09: methods = ["POST"]
10: }
11: response {
12: statuses = [401, 403]
13: }
14: }The match block tells the Cloudflare edge what to be on the lookout for, i.e., HTTP or HTTPS POST requests to https://www.example.com/login. We further restrict the match to HTTP 401/Unauthorized or 403/Forbidden response codes returned from the origin.
15: action {
16: mode = "simulate"
17: timeout = 300
18: response {
19: content_type = "text/plain"
20: body = "You have failed to login 5 times in a 60 second period and will be blocked from attempting to login again for the next 5 minutes."
21: }
22: }
23: disabled = false
24: description = "Block failed login attempts (5 in 1 min) for 5 minutes."
25: }After matching traffic, we set the action for our edge to take. When testing, it's a good idea to set the mode to simulate and review logs before taking enforcement action (see below). The timeout field here indicates that we want to enforce this action for 300 seconds (5 minutes) and the response block indicates what should be sent back to the caller that tripped the rate limit.
2. Preview and merge the changes
As usual, we take a look at the proposed plan before we apply any changes:
$ terraform plan
...
Terraform will perform the following actions:
+ cloudflare_rate_limit.login-limit
id: <computed>
action.#: "1"
action.0.mode: "simulate"
action.0.response.#: "1"
action.0.response.0.body: "You have failed to login 5 times in a 60 second period and will be blocked from attempting to login again for the next 5 minutes."
action.0.response.0.content_type: "text/plain"
action.0.timeout: "300"
description: "Block failed login attempts (5 in 1 min) for 5 minutes."
disabled: "false"
match.#: "1"
match.0.request.#: "1"
match.0.request.0.methods.#: "1"
match.0.request.0.methods.1012961568: "POST"
match.0.request.0.schemes.#: "2"
match.0.request.0.schemes.2328579708: "HTTP"
match.0.request.0.schemes.2534674783: "HTTPS"
match.0.request.0.url_pattern: "www.example.com/login"
match.0.response.#: "1"
match.0.response.0.origin_traffic: "true"
match.0.response.0.statuses.#: "2"
match.0.response.0.statuses.1057413486: "403"
match.0.response.0.statuses.221297644: "401"
period: "60"
threshold: "5"
zone: "example.com"
zone_id: <computed>
Plan: 1 to add, 0 to change, 0 to destroy.The plan looks good so let's go ahead, merge it in, and apply it.
$ git add cloudflare.tf
$ git commit -m "Step 4 - Add rate limiting rule to protect /login."
[step4-ratelimit 0f7e499] Step 4 - Add rate limiting rule to protect /login.
1 file changed, 28 insertions(+)
$ git checkout master
Switched to branch 'master'
$ git merge step4-ratelimit
Updating 321c2bd..0f7e499
Fast-forward
cloudflare.tf | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
$ terraform apply --auto-approve
cloudflare_record.www: Refreshing state... (ID: c38d3103767284e7cd14d5dad3ab8668)
cloudflare_zone_settings_override.example-com-settings: Refreshing state... (ID: e2e6491340be87a3726f91fc4148b125)
cloudflare_rate_limit.login-limit: Creating...
action.#: "" => "1"
action.0.mode: "" => "simulate"
action.0.response.#: "" => "1"
action.0.response.0.body: "" => "You have failed to login 5 times in a 60 second period and will be blocked from attempting to login again for the next 5 minutes."
action.0.response.0.content_type: "" => "text/plain"
action.0.timeout: "" => "300"
description: "" => "Block failed login attempts (5 in 1 min) for 5 minutes."
disabled: "" => "false"
match.#: "" => "1"
match.0.request.#: "" => "1"
match.0.request.0.methods.#: "" => "1"
match.0.request.0.methods.1012961568: "" => "POST"
match.0.request.0.schemes.#: "" => "2"
match.0.request.0.schemes.2328579708: "" => "HTTP"
match.0.request.0.schemes.2534674783: "" => "HTTPS"
match.0.request.0.url_pattern: "" => "www.example.com/login"
match.0.response.#: "" => "1"
match.0.response.0.origin_traffic: "" => "true"
match.0.response.0.statuses.#: "" => "2"
match.0.response.0.statuses.1057413486: "" => "403"
match.0.response.0.statuses.221297644: "" => "401"
period: "" => "60"
threshold: "" => "5"
zone: "" => "example.com"
zone_id: "" => "<computed>"
cloudflare_rate_limit.login-limit: Creation complete after 1s (ID: 8d518c5d6e63406a9466d83cb8675bb6)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.Note that if you haven't purchased rate limiting yet, you will see the following error when attempting to apply the new rule:
Error: Error applying plan:
1 error(s) occurred:
* cloudflare_rate_limit.login-limit: 1 error(s) occurred:
* cloudflare_rate_limit.login-limit: error creating rate limit for zone: error from makeRequest: HTTP status 400: content "{\n \"result\": null,\n \"success\": false,\n \"errors\": [\n {\n \"code\": 10021,\n \"message\": \"ratelimit.api.not_entitled.account\"\n }\n ],\n \"messages\": []\n}\n"3. Update the rule to ban (not just simulate)
After confirming that the rule is triggering as planned in logs (but not yet enforcing), it's time to switch from simulate to ban:
$ git checkout step4-ratelimit
$ sed -i.bak -e 's/simulate/ban/' cloudflare.tf
$ git diff
diff --git a/cloudflare.tf b/cloudflare.tf
index ed5157c..9f25a0c 100644
--- a/cloudflare.tf
+++ b/cloudflare.tf
@@ -42,7 +42,7 @@ resource "cloudflare_rate_limit" "login-limit" {
}
}
action {
- mode = "simulate"
+ mode = "ban"
timeout = 300
response {
content_type = "text/plain"$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
cloudflare_zone_settings_override.example-com-settings: Refreshing state... (ID: e2e6491340be87a3726f91fc4148b126)
cloudflare_rate_limit.login-limit: Refreshing state... (ID: 8d518c5d6e63406a9466d83cb8675bb6)
cloudflare_record.www: Refreshing state... (ID: c38d3103767284e7cd14d5dad3ab8669)
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
~ cloudflare_rate_limit.login-limit
action.0.mode: "simulate" => "ban"
Plan: 0 to add, 1 to change, 0 to destroy.4. Merge and deploy the updated rule, then push config to GitHub
$ git add cloudflare.tf
$ git commit -m "Step 4 - Update /login rate limit rule from 'simulate' to 'ban'."
[step4-ratelimit e1c38cf] Step 4 - Update /login rate limit rule from 'simulate' to 'ban'.
1 file changed, 1 insertion(+), 1 deletion(-)
$ git checkout master && git merge step4-ratelimit && git push
Switched to branch 'master'
Updating 0f7e499..e1c38cf
Fast-forward
cloudflare.tf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 361 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To git@github.com:$GITHUB_USER/cf-config.git
0f7e499..e1c38cf master -> master$ terraform apply --auto-approve
cloudflare_rate_limit.login-limit: Refreshing state... (ID: 8d518c5d6e63406a9466d83cb8675bb6)
cloudflare_record.www: Refreshing state... (ID: c38d3103767284e7cd14d5dad3ab8669)
cloudflare_zone_settings_override.example-com-settings: Refreshing state... (ID: e2e6491340be87a3726f91fc4148b126)
cloudflare_rate_limit.login-limit: Modifying... (ID: 8d518c5d6e63406a9466d83cb8675bb6)
action.0.mode: "simulate" => "ban"
cloudflare_rate_limit.login-limit: Modifications complete after 0s (ID: 8d518c5d6e63406a9466d83cb8675bb6)
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.5. Confirm the rule works as expected
This step is optional, but it's a good way to demonstrate that the rule is working as expected (note the final 429 response):
$ for i in {1..6}; do curl -XPOST -d '{"username": "foo", "password": "bar"}' -vso /dev/null https://www.example.com/login 2>&1 | grep "< HTTP"; sleep 1; done
< HTTP/1.1 401 Unauthorized
< HTTP/1.1 401 Unauthorized
< HTTP/1.1 401 Unauthorized
< HTTP/1.1 401 Unauthorized
< HTTP/1.1 401 Unauthorized
< HTTP/1.1 429 Too Many RequestsWrapping up
That's it for today! Stay tuned next week for part 2 of this post, where we continue the tour through the following resources and techniques:
Load Balancing Resource
Page Rules Resource
Reviewing and Rolling Back Changes
Importing Existing State and Configuration