Access Application resource returns an authentication error after upgrade to provider version 2.10.0

[wolfmd]

After upgrading to the latest Cloudflare provider version (2.10.0), I began getting authentication errors during plan specifically on the Access Application resource. 2.9.0 continues to work as expected. I use the environment variable CLOUDFLARE_ACCESS_TOKEN scoped specifically to Cloudflare Access-related settings

I don't see any changes to the terraform access configuration in this release however the version of cloudflare-go that is being used has changed to 0.13.1. This version of cloudflare-go does include a change to how access applications are referred which may be the source of this authentication discrepancy. cloudflare/cloudflare-go@v0.12.2...v0.13.1

I will try to update this issue with more information about possible root causes, but wanted to share it before I get too far into spelunking.

Terraform Version

Terraform v0.12.24

• provider.cloudflare v2.10.0

Affected Resource(s)

• cloudflare_access_application

Debug Output

 Error finding Access Application "85b0d517-bda6-4b83-bd37-05a344c1aa74": error from makeRequest: HTTP status 403: Authentication error

Expected Behavior

There should be no diff between access applications 2.9.0 and 2.10.0 and authentication should be the same with either version.

Actual Behavior

Authentication error on access applications

Steps to Reproduce

1. Create a Cloudflare API token with the following permissions
   Account: - Access: Service Tokens:Edit, Access: Organizations, Identity Providers, and Groups:Edit, Access: Apps and Policies:Edit
   Zone{ Access: Apps and Policies:Edit

2. Using the 2.9.0 version of the provider and the API token created in step 1, run a plan against a terraform configuration containing an access application and see that the token authenticates correctly and the resource is up to date

3. Change the version of the provider to 2.10.0 and run terraform init

4. Run a terraform plan without any further changes and note that it fails with an authentication error for every access application but not other access-related resources in the tfstate.

See Also

cloudflare/cloudflare-go@v0.12.2...v0.13.1 is possibly relevant

cc @jacobbednarz @dhaynespls

[jacobbednarz]

By the looks of things, provider version 2.10.0 shouldn't have included cloudflare-go @ v0.13.1 until #724 landed.

#724 is nearly ready to merge and we can hotfix a release following that. For now, I'd recommend sticking to 2.9.

[wolfmd]

Thanks for the quick response! Sorry I didn't see that open PR

[jacobbednarz]

I've just merged the PR and cut v2.10.1 which 🤞 should address your issue. If you're using API tokens, it may need some additional permissions but I'm not totally sure as it varies between setups.

[jacobbednarz]

Closing as 2.10.1 should handle this; if not, ping me and we'll reopen

[NikolaeVarius]

I do not believe 2.10.1 fixed this problem. 2.9.0 worked fine. Using API Tokens set in env

Terraform version: 0.12.29                                                                                                                                                                                                                    
Go runtime version: go1.12.13

On init

Initializing modules...

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "cloudflare" (terraform-providers/cloudflare) 2.10.1...

Terraform has been successfully initialized!

On Plan

Error: Error finding Access Application ****: error from makeRequest: HTTP status 403: Authentication error

Debug Log

 -----------------------------------------------------                                                                                                                                 
 2020/08/25 12:21:29 [DEBUG] Cloudflare API Request Details:                                                                                                                           
 ---[ REQUEST ]---------------------------------------                                                                                                                                 
 GET /client/v4/accounts/****/access/apps/**** HTTP/1.1                                                                    
 Host: api.cloudflare.com                                                                                                                                                              
 User-Agent: HashiCorp Terraform/0.12.29 (+https://www.terraform.io) Terraform Plugin SDK/1.15.0 terraform-provider-cloudflare/2.10.1                                                  
 Authorization: Bearer ********                                                                                                                        
 Content-Type: application/json                                                                                                                                                        
 Accept-Encoding: gzip                                                                                                                                                                 
                                                                                                                                                                                       
                                                                                                                                                                                       
 -----------------------------------------------------                                                                                                                                 
 2020/08/25 12:21:29 [DEBUG] Cloudflare API Response Details:                                                                                                                          
 ---[ RESPONSE ]--------------------------------------                                                                                                                                 
 HTTP/1.1 403 Forbidden                                                                                                                                                                
 Connection: close                                                                                                                                                                     
 Transfer-Encoding: chunked                                                                                                                                                            
 Cf-Cache-Status: DYNAMIC                                                                                                                                                              
 Cf-Ray: ******                                                                                                                                                          
 Cf-Request-Id: ******                                                                                                                                       
 Content-Type: application/json                                                                                                                                                        
 Date: Tue, 25 Aug 2020 18:21:29 GMT                                                                                                                                                   
 Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"                                                                                    
 Server: cloudflare                                                                                                                                                                    
 Vary: Accept-Encoding                                                                                                                                                                 
                                                                                                                                                                                       
 4d                                                                                                                                                                                    
 {
  "success": false,
  "errors": [
   {
    "code": 10000,
    "message": "Authentication error"
   }
  ]
 }
 
 0
 

[wolfmd]

2.10.1 fixed this for me. I'd double check that the token you're using includes Account-level Access: Apps and Policies:Edit permissions. I believe that changed somewhat recently and may be the cause of your issue here

[jkim-codecademy]

I do have that set. I can switch between provider versions not change anything else and will have broken behavior

[wolfmd]

Sorry, I didn't clarify well. The dropdown on the left allows you to select Account instead of zone sort of like:

Can you try adding the Account-level Access Apps and Policies permission to your token?

[NikolaeVarius]

That did it. Thanks

[abeluck]

Can I request this issue be re-opened? @wolfmd

Before 2.10 we could edit Access Apps using a token scoped to a specific zone.

Now, post 2.10 the "fix" is to relax security and scope the the token to a specific account. This is not ideal at all!

One account can have many domains, some production, some development. Not every developer should be able to edit Access apps and policies across the entire account.

Or am I missing something here?

[jacobbednarz]

I think you're misunderstanding the change here @abeluck. Access resources have always been an account level permission; when you would have an account member with Access permissions, it was for the entire account irrespective of zone in use. If you check your existing account members, they have always had permission to make changes on any zone using the UI or API key (well before API tokens were even around). The screenshots above are only for API token use which are intended to be limited scoped use for interactions.

The change that happened here is the route that is used for the management via the remote API. It used to live under /zones/:id however was moved to /accounts/:id to better reflect where the entitlements/permissions reside.

[abeluck]

Thanks for the clarification @jacobbednarz It was a misunderstanding indeed.

The confusion came about as we tried to move from Users with CF console access to doling out specific API keys to devs for the tasks they needed.

The API Token UI allows you to create a token with "Zone -> Access: Apps and Policies -> Edit" permissions, so the assumption was we could use a token with that permission to ensure bearers of that token could only affect policies against a specific zone.

You've clarified for me that authorization for Access resources are controlled at the account level, and has always been the case.

I've verified using Account level "Access: Apps and Policies -> Edit" permissions works with the latest cloudflare terraform provider.

(I could grumble about the fact that the Token UI lets you create a Zone scoped Access: Apps and Policies Edit permission, and I could go on about the need for orgs to allow more finely-grained control to access policies at the zone level.. but that would be rather off topic for this repo, so I won't 😉 )