Make credentials available on apigee_*_app resources after creation

[zkauker]

Hi All,

I'd like to automate the management of API proxies - including giving access to APIs for contracted partners on a managed way. When a new contracted partner comes in an apigee_company and an apigee-company-app resource will be created with a terraform script.

After this process, I'd like to save the created API keys and pass that to the contact person. However, currently the implementation does not map the credentials section back onto the terraform resource, so I cannot output that. This means that after creation I still need to login to the console and copy the API keys from there.

Is there any specific reason for this behavior? Wouldn't it make sense to map back this info as well?

Terraform Version

Terraform v0.12.9

Affected Resource(s)

• apigee_developer_app
• apigee_company_app

Expected Behavior

Credentials are set in the resource after creation.

Actual Behavior

Credentials are not available from terraform.

Important Factoids

The go-apigee-edge library supports fetching the credentials, so it's just a question of if we map this info back into the terraform resource.

[zambien]

@zkauker I've used different means to get at credentials. They've involved a custom implementation of Vault calling Apigee APIs but I don't see a reason this couldn't be included.

I think that by default I would like to not return these credentials as once they are returned they will sit in terraform state pretty much forever but add a flag which allows them to be returned.

Does that sound reasonable?

[zkauker]

@zambien sorry for the late answer. To be honest I wouldn't be too concerned about storing these values in the state file. After all if you use valuts form Terraform in your configurations it's also going to be persisted in the state and plan files. Morover, if you look into other provider implementations they do it pretty much the same way (e.g. GCP provider returns even the generated private keys for the service accounts and it gets stored in the state file as well).

My point is that configuring a properly secured backend for your state file is quite straightforward and you have many options for it, it should not be an issue.

You create these credentials for the reason that you have to use them somewhere and I think we can agree in propagating these on an automated way is always more secure than having someone who manually copies these values from the UI and sends them to the (hopefully) right place. So an alternative to humans and terraform for fetching these credentials would be some custom-crafted app, which also should be tested, hosted and executed somewhere, so it comes with a lot of effort which is unnecessary in my opinion.

So after all making this feature optional seem reasonable only if someone stores the state files on an unsecured storage which - in my opinion - should never happen. What do you think?

[bostrowski13]

I know its been a while since this was requested, but is there any timeframe for implementation?

[zambien]

Thanks for the reminder. I'll start looking into it.

[robinmeiss]

Hi Adam,

first thanks for this great work on your plugin.

I have one question to the cred management and an issue we observe chaning to v0.23.

Each app now results in an update in-place action (which afterwards lead to an additional fresh credential in Apigee for the app but still null on credential attribute in terraform state).

------------------------------------------------------------------------
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:
  # apigee_developer_app.developer_apps["example-api-app"] will be updated in-place
  ~ resource "apigee_developer_app" "developer_apps" {
        api_products    = [
            "example-api-producta",
        ]
        app_id          = "abcdefgh-1111-1111-4444-abcdefgh"
        attributes      = {
            "Display Name" = "ExampleDev App 1"
        }
      + credentials     = (known after apply)
        developer_email = "[email protected]"
        developer_id    = "ijklmnop-2222-2222-4444-abcdefgh"
        id              = "qrstuvwx-3333-3333-4444-abcdefgh"
        name            = "example-api-app"
        scopes          = [
            "test-api:read",
        ]
        status          = "approved"
    }
Plan: 0 to add, 1 to change, 0 to destroy.
------------------------------------------------------------------------

Our terraform resource looks is build with for_each and a yaml config file, but the issue also remains with a single tf resource.

resource "apigee_developer" "apigee_developers" {
  for_each = { for users in local.developers_data : users.email => users }
  email      = each.value.email
  first_name = each.value.first_name
  last_name  = each.value.last_name
  user_name  = each.value.username
  attributes = each.value.dev_attributes
}

YAML is then like:

---
apidevelopers:
- users:
  - email: [email protected]
    first_name: Example
    last_name: Developer
    username: example-user
    dev_attributes:
      Business: Example

I am not sure if this is intended behaviour or their is additional config necessary for the credential storage? Unluckily this prevents us from managing our existing apps with terraform provider. As 0.23 is the first registry version in terraform 0.13 we are quite stucked here, and I am wondering what might be wrong in our setup.

BR,
Robin

[zambien]

@robinmeiss I think this is unrelated to this issue. Could you open a new issue for this.

When testing 0.0.23 I seem to recall seeing different behavior from the Apigee APIs which may be causing this. Are you saying that this only started happening when moving from some version (which version?) to 0.0.23? If you could include the full terraform required to recreate the issue in that issue I can look into it.

[robinmeiss]

Yes I will update you with all possible logs off this one. The 0.0.22 Version is working. I think we need some time and preparation to fully reproduce the issues as with upgrading to 0.13 more stuff changed.

[zambien]

With v0.0.24 the plugin returns the last (latest) credential key and consumer key in developer and company apps. I plan to change this going forward but this should hopefully suffice for now.