Bug: Can't import cloudfoundry_service_key resources

[mogul]

GIVEN I have created a service-key by hand using cf create-service-key
AND I know the GUID of the service-key
WHEN I terraform import to the address of a cloudfoundry_service_key using the GUID as the value
THEN terraform should read the state of the addressed cloudfoundry_service_key from the live resource
BUT terraform says Error: Service credential binding not found

$ cf t
API endpoint:   [REDACTED]
API version:    3.144.0
user:           [REDACTED]
org:            [REDACTED]
space:          dev

$ cf service-keys dev-deployer
Getting keys for service instance dev-deployer as [email protected]...

name               last operation     message
dev-deployer-key   create succeeded   

$ cf service-key dev-deployer dev-deployer-key --guid
b13cee64-f21a-40b5-90b1-960a4e622119

$ terraform import 'module.environments["dev"].cloudfoundry_service_key.deployer_creds' 'b13cee64-f21a-40b5-90b1-960a4e622119'
module.environments["dev"].data.cloudfoundry_org.org: Reading...
module.environments["dev"].data.cloudfoundry_service.service_account: Reading...
module.environments["dev"].data.cloudfoundry_asg.asgs["trusted_local_networks"]: Reading...
module.environments["dev"].data.cloudfoundry_service.service_account: Read complete after 1s [id=feac1b6a-6406-4ed2-b57d-e5df192cb053]
module.environments["dev"].data.cloudfoundry_asg.asgs["trusted_local_networks_egress"]: Reading...
module.environments["dev"].data.cloudfoundry_org.org: Read complete after 1s [id=d030fa77-d07d-4164-8f15-25dbc1c04f44]
module.environments["dev"].data.cloudfoundry_asg.asgs["trusted_local_networks"]: Read complete after 0s [id=c515ab7a-c05a-40c7-b2fe-146a457336a8]
module.environments["dev"].cloudfoundry_service_key.deployer_creds: Importing from ID "b13cee64-f21a-40b5-90b1-960a4e622119"...
module.environments["dev"].data.cloudfoundry_asg.asgs["trusted_local_networks_egress"]: Read complete after 0s [id=71d5aa70-fdce-46fa-8494-aabdb8cae381]
╷
│ Error: Service credential binding not found
│ 
│ 
╵

I didn't really expect importing the key by name to work, but it elicited a response that's probably worth reporting in this context as well:

$ terraform import 'module.environments["dev"].cloudfoundry_service_key.deployer_creds' 'dev-deployer-key'
module.environments["dev"].data.cloudfoundry_service.service_account: Reading...
module.environments["dev"].data.cloudfoundry_asg.asgs["trusted_local_networks_egress"]: Reading...
module.environments["dev"].data.cloudfoundry_asg.asgs["trusted_local_networks_egress"]: Read complete after 0s [id=71d5aa70-fdce-46fa-8494-aabdb8cae381]
module.environments["dev"].data.cloudfoundry_org.org: Reading...
module.environments["dev"].data.cloudfoundry_asg.asgs["trusted_local_networks"]: Reading...
module.environments["dev"].data.cloudfoundry_service.service_account: Read complete after 0s [id=feac1b6a-6406-4ed2-b57d-e5df192cb053]
module.environments["dev"].data.cloudfoundry_org.org: Read complete after 1s [id=d030fa77-d07d-4164-8f15-25dbc1c04f44]
module.environments["dev"].data.cloudfoundry_asg.asgs["trusted_local_networks"]: Read complete after 1s [id=c515ab7a-c05a-40c7-b2fe-146a457336a8]
module.environments["dev"].cloudfoundry_service_key.deployer_creds: Importing from ID "dev-deployer-key"...
╷
│ Error: The provider returned a resource missing an identifier during ImportResourceState. This is generally a bug in the resource implementation for import. Resource import code should not call d.SetId("") or create an empty ResourceData. If the resource is missing, instead return an error. Please report this to the provider developers.
│ 
│ 
╵

[mogul]

I figured this out... The CF user with which the provider was configured had the OrgManager role, and used that role's capabilities to create the space, etc. However, that user did not have the SpaceDeveloper role in the dev space. That means the Terraform provider was unable to manipulate service instances and bindings. Once I gave the provider's CF user the SpaceDeveloper role, imports worked correctly.

I think the error message should be changed to reflect the actual "permission denied" situation, which would have pointed me directly at what was wrong and saved a lot of time!