PaloAltoNetworks / terraform-provider-prismacloud

Terraform PrismaCloud provider
https://www.terraform.io/docs/providers/prismacloud/
Mozilla Public License 2.0
54 stars 65 forks source link

Feature: new data source for API-generated External ID when onboarding AWS accounts #149

Closed erikpaasonen closed 1 year ago

erikpaasonen commented 2 years ago

Is your feature request related to a problem?

Regarding this quote from the documentation for a prismacloud_org_cloud_account (upcoming feature enhancement notes):

Lookahead Notice

Change in existing behavior of external_id and member_external_id fields to prevent confused deputy attack on AWS accounts By September 2022, the external_id and member_external_id fields in resource prismacloud_org_cloud_account will not be considered as input parameters for onboarding AWS org account. You will have to use the App Provisioner API to generate the External ID and Member External ID. This External ID is required to generate the Role ARN and grant Prisma Cloud access to your cloud account. The generated External ID will be valid for 30 days. If you don’t complete the onboarding flow within this 30-day period, you must generate a new External ID and restart the onboarding workflow. While onboarding an AWS org account, you must first use the App Provisioner API to generate the External ID and Member External ID and use them to create the AWS stack via CFT. In resource prismacloud_org_cloud_account the fields external_id and member_external_id will be converted from Required to Optional to support the backward compatibility and to ensure that already onboarded AWS org accounts should not get impacted, but terraform will ignore the value of these fields and will not detect any drift on it irrespective of the value provided in terraform script.

This seems to preclude AWS account onboarding from being completed end-to-end entirely within Terraform.

Describe the solution you'd like

Would like to see a new prismacloud_aws_external_id data source created, which hits the App Provisioner API to retrieve such a generated external ID. This data source could then be fed directly into the prismacloud_org_cloud_account resource as a calculated value. Of course, then prismacloud_org_cloud_account would have to continue to accept the external_id parameter as valid input (versus the upcoming ignore of this value per the notice).

Describe alternatives you've considered

Having to set up additional infrastructure outside of Terraform when we already use the Terraform provider to complete the process end to end. Not palatable.

Additional context

Trying to accomplish onboarding of new AWS accounts into Prisma Cloud entirely via Infra-as-Code (preferably entirely via Terraform).

welcome-to-palo-alto-networks[bot] commented 2 years ago

:tada: Thanks for opening your first issue here! Welcome to the community!

ftbrecordspan commented 1 year ago

prismacloud_aws_cft_generator data source and prismacloud_cloud_account_v2 resource introduced in v1.3.1.

erikpaasonen commented 1 year ago

@ftbrecordspan can you provide a working example of how to use the new data source? when we set the external_id attribute of the aws block as such:

data "prismacloud_aws_cft_generator" "test" {
  account_type = "account"
  account_id   = var.account_id
}

resource "prismacloud_cloud_account" "test" {
  ...
  aws {
    ...
    external_id = data.prismacloud_aws_cft_generator.test.external_id
    ...
  }
}

it creates the account entry in Cloud Accounts in the Prisma Cloud console, however we get an error on Authentication saying that the External ID is still invalid: image

following the advice of this (somewhat outdated) KB article, we have confirmed that the second condition mentioned in the error message text (namely, "ensure Prisma Cloud account is added as Trusted entity") is correctly configured, with the proper account ID copied from the KB article found in the expected ARN: image it seems the only potential problem left is the external ID value itself?

ftbrecordspan commented 1 year ago

@erikpaasonen

Please review the AWS example provided for the prisma_cloud_account_v2 resource found here. Note that this process requires the AWS IAM role as defined by the prismacloud_aws_cft_generator data source. This will ensure that the AWS IAM role implements the required permissions based on the desired Prisma Cloud capabilities, and that the role ARN and external ID are configured properly.

erikpaasonen commented 1 year ago

@erikpaasonen

Please review the AWS example provided for the prisma_cloud_account_v2 resource found here. Note that this process requires the AWS IAM role as defined by the prismacloud_aws_cft_generator data source. This will ensure that the AWS IAM role implements the required permissions based on the desired Prisma Cloud capabilities, and that the role ARN and external ID are configured properly.

our organization's security team expressly prohibits the granting of certain permissions specified in your CFN template, so we create the IAM role manually. our team has both the AWS and Terraform expertise to get the trust policy and the permissions correct. this was made clear in the discussions when the pre-announcement for this API change was first made known to us. we will not be using the CFN template resource.

since the aws block dropped support for the external_id parameter, you have made our use case incompatible with prismacloud_cloud_account_v2.

ftbrecordspan commented 1 year ago

@erikpaasonen Understood. The permissions implemented by the IAM role can be modified to suit your security requirements, but the external ID and role ARN specified by Prisma Cloud must be used as specified. The removal of the external_id param from the cloud accounts resource reflects the requirement that this value, as specified by the prismacloud_cft_generator data source, must be applied within the IAM role's trust policy.

erikpaasonen commented 1 year ago

replying for completeness: I see now that the prismacloud_cloud_account_v2 doesn't directly require any outputs which only CloudFormation can provide, which disproves my point about our use case as incompatible with it. I refactored our code to use the _v2 and ran into the issue described in https://github.com/PaloAltoNetworks/terraform-provider-prismacloud/issues/216. but as far as this data source and integrating it with a cloud account; the requested guidance has been provided, so this issue can remain closed. thanks.

ftbrecordspan commented 1 year ago

Thanks @erikpaasonen