3.0.1

• make image tag configurable and update to the latest version

Full Changelog: 3.0.0...3.0.1

3.0.0

Breaking Change!

This release requires you to update the Slack app manifest with the following additional permissions: channels:read, groups:read, and im:write. These are needed for the new “Sending Direct Messages to Users” feature. If updating the Slack app permissions isn’t possible right away, you can disable this feature by setting the send_dm_if_user_not_in_channel variable to false.

---

What's Changed

Sending Direct Messages to Users

SSO Elevator normally communicates with users via Slack channels. However, in some setups, only approvers are channel members, so no one else can see who has access where. As a result, requesters get no feedback about their requests.

To solve this, SSO Elevator can now send direct messages to users who are not in the channel. Enabling this feature requires the Slack app to have channels:read, groups:read, and im:write permissions, and the send_dm_if_user_not_in_channel variable must be set to true (this is the default).

If you’re upgrading from a previous version and cannot update the Slack app permissions immediately, disable this feature by setting send_dm_if_user_not_in_channel to false so it won’t break your current setup. When enabled, messages will be sent with the request status (for example, waiting for approval, declined, approved, etc.).

---

Secondary Subdomain Fallback Feature

Warning: This feature is strongly discouraged because it can introduce security risks.

SSO Elevator uses a Slack user’s email address to find the corresponding AWS SSO user. Sometimes, Slack addresses may differ from AWS SSO addresses (for example, john.doe@old.domain in Slack vs. john.doe@new.domain in AWS SSO). By setting secondary_fallback_email_domains, SSO Elevator will try replacing the original email domain with each fallback domain to locate the user.

Example:
Slack email: john.doe@old.domain
AWS SSO email: john.doe@new.domain

Without fallback domains, SSO Elevator won’t find the matching user. By setting secondary_fallback_email_domains = ["@new.domain"], SSO Elevator will attempt john.doe@new.domain after checking john.doe@old.domain.

Security Risks & Recommendations

• If multiple SSO users share the same local part (before the “@”) across different domains, SSO Elevator may grant permissions to the wrong user.
• Disable or remove entries in this variable as soon as you no longer need domain fallback functionality. Maintaining consistent, verified email domains in both Slack and AWS SSO is always best practice.
• SSO Elevator will update the channel request message with a warning if fallback domains are in use.

Notes:

• SSO Elevator always prioritizes the primary domain from Slack (the Slack user's email) when searching for a user in AWS SSO.
• SSO Elevator adds a large warning message in Slack if it uses a secondary fallback domain to find a user in AWS SSO.
• The secondary domain feature works ONLY for the requester, approvers in the configuration must have the same email domain as in Slack.
• New secondary_domain_was_used entry was added to the audit logs. (The Athena query was updated as well)

---

Allow Limiting Requests from the Internet

This module now includes variables to control API Gateway throttling:

variable "api_gateway_throttling_burst_limit" {
  description = "The maximum number of requests that API Gateway allows in a burst."
  type        = number
  default     = 5
}

variable "api_gateway_throttling_rate_limit" {
  description = "The maximum number of requests that API Gateway allows per second."
  type            = number
  default        = 1
}

---

Improved Error Handling

When the initial form is displayed, SSO Elevator now checks whether the requester has a corresponding user in AWS SSO. If not, Elevator sends a message to the Slack channel indicating the issue.

---

Updated Text for the “Why Do You Need Access?” Field

Previously, this field was labeled “write something.” It is now updated to:

“Reason will be saved in audit logs. Please be specific.”

---

Permission duration list override by @philomory

An explicit list of duration values to appear in the drop-down menu users use to select how long to request permissions for. Each entry in the list should be formatted as "hh:mm", e.g. "01:30" for an hour and a half. Note that while the number of minutes must be between 0-59, the number of hours can be any number. If this variable is set, the max_permission_duration_time is ignored.

---

Other Changes

• Dependabot is now used to manage dependencies.
• SECURITY.md has been updated to exclude 1.. and include 2.. and 3...
• All Terraform & Python dependencies have been updated.
• Tests have been updated to include new configuration variables.
• Upd readme to include documentation on delegation of SSO & how it works with elevator
• Update variable description to adress #109
• Fix #110 SlackObjectFormationError when trying to build access request view by adding a limit of 99 elements.

---

Contributors

• @philomory made their first contribution in #111
• Feature/explicit duration list by @philomory in #111
• Update dependabot.yml by @cageyv in #106

Full Changelog: 2.0.2...3.0.0

2.0.2

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

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

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

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

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

What's Changed@

• Features

  • Change initial form text- “What is it you are going to do” to "Why do you need access?"
  • Add color coding for messages in the channel:
    • Green for approved
    • Red for discarded
    • Yellow for waiting
    • White for expired

• Fixed bugs:

  • Fix handling 24h:00m requests as a 00:00, now elevator will handle requests for more than a day in format : 1d 12h 30m
  • Pin terraform-local version to fix localstack

Full Changelog: 1.2.2...1.3.0

1.2.2

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

What's Changed

• Bump urllib3 from 1.26.16 to 1.26.18 in /src by @dependabot in #61
• Bump certifi from 2023.5.7 to 2023.7.22 in /src by @dependabot in #63

New Contributors

• @dependabot made their first contribution in #61

Full Changelog: 1.2.0...1.2.1