Skip to content

Releases: fivexl/terraform-aws-sso-elevator

2.0.2

04 Oct 13:33
Compare
Choose a tag to compare

Problem

This release addresses an issue in the Lambda function where the case-sensitive comparison of email addresses from Slack and AWS SSO caused a failure in user lookups. We’ve modified the email comparison to be case-insensitive to better align with AWS SSO behavior, which is not case-sensitive for email addresses.

Changes:

Updated the get_user_principal_id_by_email function to perform case-insensitive email comparison using the lower() function.
Previous implementation compared the email directly using ==, which failed when there were differences in case between Slack emails and AWS SSO emails.
Now, both the Slack-provided email and the AWS SSO email are normalized to lowercase before comparison, ensuring consistent results regardless of case differences.
Full Changelog: 2.0.1...2.0.2

2.0.1

09 Sep 11:00
Compare
Choose a tag to compare

Fixes:

The previous version (2.0.0) used an outdated 1.4.0 version of the image for the SSO Elevator when using a pre-created image. This release updates the Lambdas to use the newer 2.0.1 image version.

Full Changelog: 2.0.0...2.0.1

2.0.0

09 Sep 09:38
Compare
Choose a tag to compare

BREAKING CHANGES:

We have added more information to the audit entry. Please refer to the section '## New Audit Entry' for details.
Changes in Slack App manifest. Please refer to the end of '## Group Assignments Mode' for details.

In releases prior to 2.0.0, Elevator did not check for double slashes in the path of the Audit entry bucket, which could cause Athena queries to fail. If your S3 bucket contains double slashes in the path, you can run the provided script to fix the issue. You can find the script here. Replace SOURCE_PREFIX, DESTINATION_PREFIX, and BUCKET_NAME with your own values.

Group Assignments Mode

Starting from version 2.0, Terraform AWS SSO Elevator introduces support for group access. Users can now use the /group-access command, which, instead of showing the form for account assignments, will present a Slack form where users can select the group they want access to, specify a reason, and define the duration for which access is required.

The basic logic for access, configuration, and Slack integration remains the same as before. To enable the new Group Assignments Mode, you need to provide the module with the new group_config Terraform variable:

group_config = [
    {              
      "Resource" : ["99999999-8888-7777-6666-555555555555"], #ManagementAccountAdmins
      "Approvers" : [
        "email@gmail.com"
      ]
      "ApprovalIsNotRequired": true
    },
    {              
      "Resource" : ["11111111-2222-3333-4444-555555555555"], #prod read only
      "Approvers" : [
        "email@gmail.com"
      ]
      "AllowSelfApproval" : true,
    },
    {
      "Resource" : ["44445555-3333-2222-1111-555557777777"], #ProdAdminAccess
      "Approvers" : [
        "email@gmail.com"
      ]
    },
]

There are two key differences compared to the standard Elevator configuration:

  • ResourceType is not required for group access configurations.
  • In the Resource field, you must provide group IDs instead of account IDs.
    The Elevator will only work with groups specified in the configuration.

If you were using Terraform AWS SSO Elevator before version 2.0.0, you need to update your Slack app manifest by adding a new shortcut to enable this functionality:

{
  "name": "group-access",
  "type": "global",
  "callback_id": "request_for_group_membership",
  "description": "Request access to SSO Group"
}

To disable this functionality, simply remove the shortcut from the manifest.

New Information in Audit Entry

Starting with version 2.0.0, the audit entry will now include the following new fields:

    version = 1
    group_name: Literal["NA"] | str = "NA"
    group_id: Literal["NA"] | str = "NA"
    group_membership_id: Literal["NA"] | str = "NA"
    audit_entry_type: Literal["group"] | Literal["account"]

Additionally, any entry can use "NA" as a placeholder for missing information, except for the following fields:

reason: Literal["scheduled_revocation"] | Literal["automated_revocation"] | str
operation_type: Literal["grant"] | Literal["revoke"]
audit_entry_type: Literal["group"] | Literal["account"]

Other changes:

  • Allow changing the log retention for API Gateway and Lambda functions by providing var.logs_retention_in_days.
  • Pass var.tags to the API Gateway module.
  • Added a script to fix file paths in S3.
  • Now, if a user tries to use a mode of the SSO Elevator that doesn't have any statements configured, the Elevator will send a message about it in Slack.

Full Changelog: 1.4.1...2.0.0

1.4.1

10 Jul 09:07
Compare
Choose a tag to compare

This version of the module is a copy of the 1.4.0 release, but with the "cycle" bug fix and a couple of changes. If you are migrating from version 1.3.0, please use this version of the module.

1.4.1 release allows you to migrate from Lambda URL using the API Gateway more seamlessly. You can have both a Lambda URL and an API Gateway endpoint at the same time, enabling a smoother migration process. To control this behavior, please use the following variables:

ecr_repo_name = "example_repo_name"
ecr_owner_account_id = "<example_account_id>"

output "requester_api_endpoint_url" {
  description = "The API Gateway URL to invoke the Lambda function"
  value       = module.aws_sso_elevator.requester_api_endpoint_url
}

output "lambda_function_url" {
  description = "The Lambda Function URL to invoke the Lambda function"
  value       = module.aws_sso_elevator.lambda_function_url
}

Additionally, this release no longer relies on the creation of the FunctionURLAllowPublicAccess policy by the aws_lambda_function_url resource. Instead, it creates and manages a new AllowExecutionFromLambdaURL resource-based policy for the Lambda function.

1.4.0 Release:

Breaking Changes!

Build

Before this release, there were two ways to build zip files for Elevator lambdas:

  • Locally using the local environment
  • Locally using Docker build

Building zips locally without Docker created many problems with Python environments, where an incorrect Python version could break the build. In this release, we decided to remove the ability to use the local environment entirely.

Now, with every release, a GitHub CI will be triggered that pre-builds requester and revoker lambda Docker images and pushes them to FivexL's private ECR. Users will be able to pull these pre-built Docker images to build lambdas.

ECR is private for the following reasons:

  • AWS Lambda can't use any other source of images except ECR.
  • AWS Lambda can't use public ECR.
  • AWS Lambda doesn't support pulling container images from Amazon ECR using a pull-through cache rule (so we can't create a private repo on the user side to pull images from the GHCR, for example).

The private ECR created by FivexL is accessible only for the read-only actions necessary to pull images by the lambdas. Images and repositories are replicated in every region that AWS SSO supports.

Conclusion:
Now there are only two ways to build an SSO elevator:

  • By using pre-created images pulled from ECR (Default)
  • By using Docker build to build images locally. (To use this method, provide the module with the following variable: use_pre_created_image = false)

There is also the ability to host ECR yourself. To do so, you would need to provide SSO Elevator with the following two variables:

ecr_repo_name = "example_repo_name"
ecr_owner_account_id = <example_account_id>

The elevator will then try to pull images from your private ECR repo.

API

After updating the module, you can find the API URL in the output of the module. Please don't forget to update the Slack App manifest with the new URL.

In previous releases, the terraform-aws-sso-elevator module was triggering the lambda-1 SecurityHub control. This happened because, by default, when creating the aws_lambda_function_url resource, the Terraform provider would create a FunctionURLAllowPublicAccess resource-based policy for the lambda on your behalf (but would not delete it after the resource's destruction. More information can be found here).

To address the SecurityHub control alert, we decided to migrate to using API Gateway. Now the module will create and use API Gateway by default. The lambda URL is now deprecated, and the ability to use it will be removed in future releases. If you need to continue using the lambda URL, provide the module with the following variable:

use_deprecated_lambda_url = true

Due to the issue in the Terraform provider, if you migrate to API Gateway from using the Lambda URL, you will still have problems with SecurityHub because the Terraform provider will not delete the policy on your behalf, it will only create it. To fix the SecurityHub issue, you need to go to the AWS Console where your SSO Elevator is deployed, navigate to Lambda service/configuration/permissions/Resource-based policy statements, and delete the FunctionURLAllowPublicAccess policy statement.

Other

  • Updated documentation to address module changes.
  • Documentation changes by pre-commit terraform-doc hook.
  • Small typo fixes by code-spell hook.
  • Updated dependencies by Dependabot.
  • Updated S3 object upload to use server-side encryption.
  • Using baseline-s3 module to standardize and simplify configuration management of the S3 audit bucket. Now the bucket forces uploaded objects to be encrypted by default. More information about the baseline bucket can be found here: terraform-aws-account-baseline.
    FMT.
  • Renaming of EventBridge and IAM resources to follow naming conventions, which will cause resource recreation:
    • sso_elevator_check_on_inconsistency to - sso-elevator-check-on-inconsistency
    • sso_elevator_scheduled_revocation to sso-elevator-scheduled-revocation
    • event-bridge-role-for-sso-elevator to sso-elevator-event-bridge-role

Full Changelog 1.4.0 -> 1.4.1: 1.4.0...1.4.1
Full Changelog 1.3.0 -> 1.4.1: 1.3.0...1.4.1

1.4.0

09 Jul 07:35
Compare
Choose a tag to compare

This release contains a cycle bug. Please use the next 1.4.1 tag.

Breaking Changes!

Build

Before this release, there were two ways to build zip files for Elevator lambdas:

  • Locally using the local environment
  • Locally using Docker build

Building zips locally without Docker created many problems with Python environments, where an incorrect Python version could break the build. In this release, we decided to remove the ability to use the local environment entirely.

Now, with every release, a GitHub CI will be triggered that pre-builds requester and revoker lambda Docker images and pushes them to FivexL's private ECR. Users will be able to pull these pre-built Docker images to build lambdas.

ECR is private for the following reasons:

  • AWS Lambda can't use any other source of images except ECR.
  • AWS Lambda can't use public ECR.
  • AWS Lambda doesn't support pulling container images from Amazon ECR using a pull-through cache rule (so we can't create a private repo on the user side to pull images from the GHCR, for example).

The private ECR created by FivexL is accessible only for the read-only actions necessary to pull images by the lambdas. Images and repositories are replicated in every region that AWS SSO supports.

Conclusion:
Now there are only two ways to build an SSO elevator:

  • By using pre-created images pulled from ECR (Default)
  • By using Docker build to build images locally. (To use this method, provide the module with the following variable: use_pre_created_image = false)

There is also the ability to host ECR yourself. To do so, you would need to provide SSO Elevator with the following two variables:

ecr_repo_name = "example_repo_name"
ecr_owner_account_id = <example_account_id>

The elevator will then try to pull images from your private ECR repo.

API

After updating the module, you can find the API URL in the output of the module. Please don't forget to update the Slack App manifest with the new URL.

In previous releases, the terraform-aws-sso-elevator module was triggering the lambda-1 SecurityHub control. This happened because, by default, when creating the aws_lambda_function_url resource, the Terraform provider would create a FunctionURLAllowPublicAccess resource-based policy for the lambda on your behalf (but would not delete it after the resource's destruction. More information can be found here).

To address the SecurityHub control alert, we decided to migrate to using API Gateway. Now the module will create and use API Gateway by default. The lambda URL is now deprecated, and the ability to use it will be removed in future releases. If you need to continue using the lambda URL, provide the module with the following variable:

use_deprecated_lambda_url = true

Due to the issue in the Terraform provider, if you migrate to API Gateway from using the Lambda URL, you will still have problems with SecurityHub because the Terraform provider will not delete the policy on your behalf, it will only create it. To fix the SecurityHub issue, you need to go to the AWS Console where your SSO Elevator is deployed, navigate to Lambda service/configuration/permissions/Resource-based policy statements, and delete the FunctionURLAllowPublicAccess policy statement.

Other

  • Updated documentation to address module changes.
  • Documentation changes by pre-commit terraform-doc hook.
  • Small typo fixes by code-spell hook.
  • Updated dependencies by Dependabot.
  • Updated S3 object upload to use server-side encryption.
  • Using baseline-s3 module to standardize and simplify configuration management of the S3 audit bucket. Now the bucket forces uploaded objects to be encrypted by default. More information about the baseline bucket can be found here: terraform-aws-account-baseline.
    FMT.
  • Renaming of EventBridge and IAM resources to follow naming conventions, which will cause resource recreation:
    • sso_elevator_check_on_inconsistency to - sso-elevator-check-on-inconsistency
    • sso_elevator_scheduled_revocation to sso-elevator-scheduled-revocation
    • event-bridge-role-for-sso-elevator to sso-elevator-event-bridge-role

Full Changelog: 1.3.1...1.4.0

1.3.0

1.2.2

30 Nov 13:36
Compare
Choose a tag to compare

Release Notes

  • Added pagination to the identity store's list of users, allowing the module to work with more than 100 users.
    Full Changelog: 1.2.1...1.2.2

1.2.1

26 Oct 06:27
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: 1.2.0...1.2.1

1.2.0

13 Sep 09:39
Compare
Choose a tag to compare

Release Notes

BREAKING CHANGES

Explicit Deny Logic

Introduced an advanced control mechanism that enables explicit denial of self-approval and automatic approvals in various scenarios.

In the system, an explicit denial stipulated in any statement overrides any approvals. For instance, if one statement designates an individual as an approver for all accounts, but another statement specifies that the same individual is not allowed to self-approve or to bypass the approval process for a particular account and permission set (by setting allow_self_approval and approval_is_not_required to False), then that individual will not be able to approve requests for that specific account. This enforces stricter control.

Default Values

Updated the default values for the approval_is_not_required and allow_self_approval attributes to None. This change ensures that the previous default setting of False will not deny all self-approval and approval-not-required requests automatically.

Slack App Scope

In previous releases, it was not mentioned that the scope of the Slack app permissions needed to be updated to ensure the proper functioning of the new discard buttons feature. Please ensure that your scope includes all the necessary permissions:

  • commands: This permission adds shortcuts and/or slash commands that people can use.
  • chat:write: This permission allows the app to post messages to Slack.
  • users:read and users:read.email: These permissions enable the app to find user email addresses, a necessary feature for creating AWS account assignments and including user mentions in requests.
  • channels:history: This permission allows the app to find old messages, which facilitates handling "discard button" events.

Other Improvements:

Optional SNS DQL Email

Made the SNS DQL email optional for both lambdas, offering more flexibility in the configuration settings.

Test Case Adjustments

Corrected and implemented additional test cases to align with the newly implemented explicit deny logic.

1.1.1

08 Sep 13:04
Compare
Choose a tag to compare
  • fix IAM permission to avoid multiple approver reminders sent instead of one
  • use human readable time in approver reminders

Full Changelog: 1.1.0...1.1.1