terraform-provider-aws: aws_elasticsearch_domain cognito_options cause Cycle Error

@bnr242003 What we ended up doing was using terraform to still manage our aws_elasticsearch_domain with Cognito enabled, together with our Cognito related resources (i.e. aws_cognito_user_pool, aws_cognito_user_pool_domain, aws_cognito_identity_provider, and aws_cognito_identity_pool).

After doing a tf plan/apply, our pipeline will run a post-apply.sh script, which uses the AWS CLI to directly modify the UserPoolClient AWS automatically creates for you, in order to support our SAML identity provider.

See this gist for an example of how that works. Obviously, your use case may be different: https://gist.github.com/jleskovar-tyro/051317370190394d551f8861fb760f68

If you use this approach, you’ll need to be sure to add the appropriate lifecycle.ignore_changes to any TF resources that are modified by the post-apply.sh script, or AWS itself. In our case, we had to ignore changes to cognito_identity_providers on our TF-managed aws_cognito_identity_pool resource, as otherwise the next tf plan/apply would revert the UserPoolClient AWS automatically creates and attaches for you. Hope that makes sense

Hi there. Putting aside the cyclic dependency issue you mention, my experience with ElasticSearch and cognito so far is that it simply isn’t possible to have Terraform manage cognito with ElasticSearch. The problem I’ve been having is that enabling Cognito auth for ES results in AWS going rogue and creating its own application client on the user pool you specify, as well as adding this client as an auth provider on your identity pool. My current workaround is to use the AWS CLI to configure cognito, after using Terraform to enable cognito on the ElasticSearch domain. Doing this, you’ll need to use “ignore_changes” on your identity pool to prevent TF from blowing away the AWS-managed app client

Any updates on this issue? We’re experiencing this, I’d rather not ignore changes on resources or use a script to make changes after tf apply as part of CI.

I’m using the provisioner to set the callback urls, and the rest of the configuration, after the Elasticsearch domain is created. However, the proper solution (i.e. separate resource) would be highly appreciated.

resource "aws_cognito_user_pool_client" "es_user_pool_client" {
  lifecycle {
    ignore_changes = [
      supported_identity_providers,
      callback_urls,
      logout_urls,
      allowed_oauth_flows,
      allowed_oauth_scopes,
      allowed_oauth_flows_user_pool_client
    ]
  }
}

resource "aws_elasticsearch_domain" "es" {
  provisioner "local-exec" {
    interpreter = ["/bin/bash", "-c"]
    command = <<-COMMAND
      aws cognito-idp update-user-pool-client \
        --user-pool-id ${aws_cognito_user_pool.es_pool.id} \
        --client-id ${aws_cognito_user_pool_client.es_user_pool_client.id} \
        --supported-identity-providers "COGNITO" \
        --callback-urls "https://${self.kibana_endpoint}app/kibana" \
        --logout-urls  "https://${self.kibana_endpoint}app/kibana" \
        --allowed-o-auth-flows "code" \
        --allowed-o-auth-scopes "email" "openid" \
        --allowed-o-auth-flows-user-pool-client \
        --region ${data.aws_region.current.name}
    COMMAND
  }
}

data "aws_region" "current" {}

It feels like the solution here would be to split out the cognito_identity_providers {} block and replace it with a cognito_identity_provider_association resource that would work something like this:

cognito_identity_provider_association {
    identity_pool_id = aws_cognito_identity_pool.name.id
    client_id = ""
    provider_name = ""
}

Similar kind of issue that was seen with security groups/IAM roles that necessitated a separate associative resource to prevent these kinds of annoying overlaps you can’t control in a singular definition.

Hello,

as @jleskovar-tyro mentioned, when you enable cognito authentication on ES, AWS will automatically create a new cognito app client in the background.

This renders the app client you want created via Terraform to be used via ES useless, as the configuration on ES references the AWS created app client I think?

The only work around I can think of is to data source the app client that gets created via AWS.

But then this would require two deployments, as the app client cannot be data sourced until it is created, so you would have to comment out the “cognito_identity_providers” block in the “aws_cognito_identity_pool” resource first (and any roles attachment resources). Deploy to enable cognito authentication for kibana on ES. Then remove the commented out code (adding the data sourced app client to the configuration) and deploy again?

@jleskovar-tyro Still using the post install approach? Do you happen to have an example of the terraform code as well?

I’m using the provisioner to set the callback urls, and the rest of the configuration, after the Elasticsearch domain is created. However, the proper solution (i.e. separate resource) would be highly appreciated.

resource "aws_cognito_user_pool_client" "es_user_pool_client" {
  lifecycle {
    ignore_changes = [
      supported_identity_providers,
      callback_urls,
      logout_urls,
      allowed_oauth_flows,
      allowed_oauth_scopes,
      allowed_oauth_flows_user_pool_client
    ]
  }
}

resource "aws_elasticsearch_domain" "es" {
  provisioner "local-exec" {
    interpreter = ["/bin/bash", "-c"]
    command = <<-COMMAND
      aws cognito-idp update-user-pool-client \
        --user-pool-id ${aws_cognito_user_pool.es_pool.id} \
        --client-id ${aws_cognito_user_pool_client.es_user_pool_client.id} \
        --supported-identity-providers "COGNITO" \
        --callback-urls "https://${self.kibana_endpoint}app/kibana" \
        --logout-urls  "https://${self.kibana_endpoint}app/kibana" \
        --allowed-o-auth-flows "code" \
        --allowed-o-auth-scopes "email" "openid" \
        --allowed-o-auth-flows-user-pool-client \
        --region ${data.aws_region.current.name}
    COMMAND
  }
}

data "aws_region" "current" {}

It does not seem like a working approach. When AWS Opensearch creates the app client in your User Pool it stores its client ID and secret, which it uses later during login process for the authentication redirect to Cognito User Pool. So Opensearch is locked to the app client it has created. And what happens if you clean up that original client app named AmazonOpenSearchService-bla-bla is that your Domain will be broken:

And it seems there is no way to set ClientID and Client Secret through the Opensearch control API.

ah, this is not possible: https://www.terraform.io/docs/providers/aws/d/cognito_user_pool_client.html

Hi everyone. In the AWS documentation for Amazon OpenSearch (the AWS rebranding of Elastiseach), it states

You don’t need to add external identity providers to the identity pool. When you configure OpenSearch Service to use Amazon Cognito authentication, it configures the identity pool to use the user pool that you just created.

From my understanding, in your aws_cognito_identity_pool, you should be able to leave out the cognito_identity_providers and AWS will configure it. Note that you will have to ignore changes to that field using lifecycle.ignore_changes.

In the acceptance tests for aws_elasticsearch_domain we do the following

resource "aws_elasticsearch_domain" "test" {
  ...

  cognito_options {
    enabled          = true
    user_pool_id     = aws_cognito_user_pool.test.id
    identity_pool_id = aws_cognito_identity_pool.test.id
    role_arn         = aws_iam_role.test.arn
  }

  ...
}

resource "aws_cognito_identity_pool" "test" {
  identity_pool_name               = %[1]q
  allow_unauthenticated_identities = false

  lifecycle {
    ignore_changes = [cognito_identity_providers]
  }
}

Unfortunately, this isn’t well documented.

Does this address the problem for you?

I think this issue could be solved if terraform had a data source for Cognito client app (with support for regex filter on name) and an independent resource for adding Cognito identity providers to an existing identity pool.

Some quick solution will be appreciated. Please let me know if you need anymore clarifications.