PLT-1666 : Update lambda function module to support deployment and testing via Tofu#456
PLT-1666 : Update lambda function module to support deployment and testing via Tofu#456
Conversation
|
|
||
| permissions_boundary = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:policy/cms-cloud-admin/developer-boundary-policy" | ||
|
|
||
| assume_role_policy = data.aws_iam_policy_document.function_assume_role.json |
There was a problem hiding this comment.
I need to dig into if this is still relevant in our permissions setup.
| repos = { | ||
| bcda = [ | ||
| "repo:CMSgov/bcda-app:*", | ||
| ] | ||
| cdap = [ | ||
| "repo:CMSgov/cdap:*", | ||
| ] | ||
| dpc = [ | ||
| "repo:CMSgov/dpc-app:*", | ||
| ] | ||
| } |
There was a problem hiding this comment.
These are moved into a variable in the case that repositories are managing deployment. See variable github_actions_repos
| data "aws_ssm_parameter" "prod_account_id" { | ||
| count = var.env == "test" ? 1 : 0 | ||
| name = "/prod/account-id" | ||
| } |
There was a problem hiding this comment.
cdap-mgmt is being deprecated in favor of a cdap- vpc managing lambdas in a dedicated fashion within accounts: cross-account access is no longer relevant.
| description = "Optional list of additional KMS key ARNs the Lambda can use" | ||
| type = list(string) | ||
| default = [] | ||
| } |
There was a problem hiding this comment.
Is this used anywhere? Do we have a use case for this?
… be easily used elsewhere.
| source_dir_excludes = [ | ||
| "__pycache__", | ||
| "test_*.py", | ||
| "*.pyc", |
| } | ||
|
|
||
| # Allow access from GitHub-hosted runners via OIDC for integration tests | ||
| dynamic "statement" { |
There was a problem hiding this comment.
Are these changes covered in tests somewhere in the cdap repo? Any additional workflow changes required?
I reckon this might be a larger effort and should be moved to a separate PR, but please let me know where I can review
There was a problem hiding this comment.
I updated this PR with a test function that will also come up and down on apply.
| variable "log_retention_days" { | ||
| description = "Number of days to retain Lambda function logs in CloudWatch. If null, no retention policy is set and retention is managed externally (e.g., via cdap/scripts/set_log_retention/)." | ||
| type = number | ||
| default = 180 |
There was a problem hiding this comment.
If we already have a mechanism to manage logs and there's a program-wide standard for retention period, it might be easier to make this optional/default to null.
Then default log retention period for CW logs only lives in one place. This way, if default needs to change from 180 days to 90 days for example, there are less moving pieces.
|
I verified the webhook_urls already exist for DPC on parameter store ✅ Changes in function module for CI/CD enablement are not clear to me ❌
|
## 🎫 Ticket https://jira.cms.gov/browse/AB2D-7227 ## 🛠 Changes Bumps the version of the aws provider to v6, and alters one field deprecated in the new version. ## ℹ️ Context AB2D is upgrading Java to version 25, and the aws provider v5 only supports up to version 21. This change keeps the version of the aws provider aligned and prevents mismatch errors on AB2Ds side. This change will support upgrades to java in this PR: CMSgov/ab2d#1769 ## 🧪 Validation Updated platform ref used in the AB2D lambdas, works as expected and can find Java25.
## 🎫 Ticket DPC-5387 ## 🛠 Changes <!-- What was added, updated, or removed in this PR? --> - define new _optional_ input variable for bucket module's encryption key - default behavior remains exactly the same ## ℹ️ Context <!-- Why were these changes made? Add background context suitable for a non-technical audience. --> <!-- If any of the following security implications apply, this PR must not be merged without Stephen Walter's approval. Explain in this section and add @SJWalter11 as a reviewer. - Adds a new software dependency or dependencies. - Modifies or invalidates one or more of our security controls. - Stores or transmits data that was not stored or transmitted before. - Requires additional review of security implications for other reasons. --> - For DPC's we have a use case where we want to explicitly specify a key for s3 to use for encrypting files. - For quicksight reporting, the same bucket is used by - 1. postgres extension(s) to output data - Example query `create_job()` query [HERE](https://github.com/CMSgov/dpc-app/blob/main/scripts/schedule_view_exports.sql#L43) - 2. python lambda to process data into a report - Previous dpc-ops changes relied on a free-floating feature branch from this repository specified [HERE](https://github.com/CMSgov/dpc-ops/blob/f19985817a3165bd2e227914b2c557ef7575849d/terraform/lambda/quicksight-reports/main.tf#L79) - This PR is intended to be merged before further dpc-ops changes to avoid code becoming brittle based on a separate branch ## 🧪 Validation <!-- How were the changes verified? Did you fully test the acceptance criteria in the ticket? Provide reproducible testing instructions and screenshots if applicable. --> Tested in dpc `test` environment. See Validation section in dpc-ops PR: CMSgov/dpc-ops#947 --------- Co-authored-by: Julian Scott <julianscott@navapbc.com>
## 🎫 Ticket https://jira.cms.gov/browse/BCDA-9967 ## 🛠 Changes Adding `model_name` to the production and sandbox jobs view ## ℹ️ Context We want to have the Alternative Payment Model included in job request data so that it can be easily aggregated, without having to derive the model from each entity's CMS ID ## 🧪 Validation Executed queries against prod/sandbox locally
## 🎫 Ticket https://jira.cms.gov/browse/BCDA-9967 ## 🛠 Changes Updated column order to match the existing view ## ℹ️ Context Postgres rigidly maintains the existing column order for the existing view unless we drop and recreate the view. The earlier PR merged (#461) yields error: ``` SQL Error [42P16]: ERROR: cannot change name of view column "cms_id" to "benes_attributed_to_aco" Hint: Use ALTER VIEW ... RENAME COLUMN ... to change name of view column instead. ``` ## 🧪 Validation Executed/Updated views (without errors) and checked retrieved data
## 🎫 Ticket PLT-1661 ## 🛠 Changes <!-- What was added, updated, or removed in this PR? --> Migrates python checks to leverage sonarqube and snyk for linting and security validation. Enables a common workflow that is then called by relevant python check workflows on python paths in scripts/ or in terraform paths with /lambda_src/. Sets up a snyk token for usage in a CDAP specific organization in CMS snyk. ## ℹ️ Context <!-- Why were these changes made? Add background context suitable for a non-technical audience. --> These changes were made to use standard code scanning tools provided by CMS. <!-- If any of the following security implications apply, this PR must not be merged without Stephen Walter's approval. Explain in this section and add @SJWalter11 as a reviewer. - Adds a new software dependency or dependencies. - Modifies or invalidates one or more of our security controls. - Stores or transmits data that was not stored or transmitted before. - Requires additional review of security implications for other reasons. --> ## 🧪 Validation The workflow can be validated once merged. The python-checks script was run locally which works for snyk scanning and configuring sonar, but does not test full evaluation for sonar as the project cannot be created with the common user credentials. <!-- How were the changes verified? Did you fully test the acceptance criteria in the ticket? Provide reproducible testing instructions and screenshots if applicable. -->
4cdd4ab to
8743178
Compare
🎫 Ticket
PLT-1666
🛠 Changes
Alarm-to-slack function changes:
Lambda function changes:
The function module no longer includes SQS or broad SSM permissions in its default policy. Callers must now pass these in explicitly via:
** Callers must now import existing cloudwatch log groups for management by the function module **
Lambda function testing:
Security group modifications were not made as part of these changes.
ℹ️ Context
These changes were motivated by updating the alarm-to-slack lambda predictably from source code in the CDAP repository. Additional enhancements were made to ensure IAM is refined for this function, which uplifted needs to refine the IAM broadly, enhance testablity, and ensure delivery pipeline predictability.
🧪 Validation
After initial review, these changes will be deployed to cdap-test and a test alarm will be sent via SNS topic for evaluation.
Details
Changes will be applied to bcda-test as in the git workflow plan output. 1. A test alarm will be sent via AB2D's sns topic 2. A test alarm will be sent via DPC's sns topicDetails
Changes will be applied to cdap-test as in the git workflow plan output.