Integration tests executed on a real deployment as part of the CICD - Redshift Datasets #1619
Assignees
Labels
Comments
This was referenced Oct 10, 2024
Merged
dlpzx
added a commit
that referenced
this issue
Oct 15, 2024
… Redshift Connections (#1628)⚠️ NEEDS SOME CHANGES AFTER #1638 is merged ### Feature or Bugfix - Feature: Testing ### Detail Add integration tests for Redshift connections It also includes the global conftest fixtures that will be used for redshift-datasets and redshift dataset sharing At the moment it assumes Redshift infrastructure is already provided; we might want to implement the deployment of this pre-required infra, but that can be done on a separate PR. +++ Additional fixes found during testing and fixed in this PR - Fixed Pivot role permissions in CDK when no workgroups are defined (it handled None wrong) - Add update environment stack on Connection delete to ensure permissions to pivot role are removed ### Testing - Fixes deployed in CICD pipeline in AWS - Tests executed locally (in this case we can be sure it will work as in AWS as there are no AWS Clients, just API calls)  ### Relates - #1619 - #1220 ### Security Please answer the questions below briefly where applicable, or write `N/A`. Based on [OWASP 10](https://owasp.org/Top10/en/). - Does this PR introduce or modify any input fields or queries - this includes fetching data from storage outside the application (e.g. a database, an S3 bucket)? - Is the input sanitized? - What precautions are you taking before deserializing the data you consume? - Is injection prevented by parametrizing queries? - Have you ensured no `eval` or similar functions are used? - Does this PR introduce any functionality or component that requires authorization? - How have you ensured it respects the existing AuthN/AuthZ mechanisms? - Are you logging failed auth attempts? - Are you using or adding any cryptographic features? - Do you use a standard proven implementations? - Are the used keys controlled by the customer? Where are they stored? - Are you introducing any new policies/roles/users? - Have you used the least-privilege principle? How? By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
dlpzx
added a commit
that referenced
this issue
Oct 16, 2024
… Redshift Datasets (#1636)⚠️ MERGE AFTER #1628 ### Feature or Bugfix - Feature: Testing ### Detail Add integration tests for Redshift datasets It also includes the global conftest fixtures that will be used for redshift dataset sharing At the moment it assumes Redshift infrastructure is already provided; we might want to implement the deployment of this pre-required infra, but that can be done on a separate PR. ## Testing Tested locally:  ### Relates - #1619 - #1220 ### Security Please answer the questions below briefly where applicable, or write `N/A`. Based on [OWASP 10](https://owasp.org/Top10/en/). - Does this PR introduce or modify any input fields or queries - this includes fetching data from storage outside the application (e.g. a database, an S3 bucket)? - Is the input sanitized? - What precautions are you taking before deserializing the data you consume? - Is injection prevented by parametrizing queries? - Have you ensured no `eval` or similar functions are used? - Does this PR introduce any functionality or component that requires authorization? - How have you ensured it respects the existing AuthN/AuthZ mechanisms? - Are you logging failed auth attempts? - Are you using or adding any cryptographic features? - Do you use a standard proven implementations? - Are the used keys controlled by the customer? Where are they stored? - Are you introducing any new policies/roles/users? - Have you used the least-privilege principle? How? By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
dlpzx
added a commit
that referenced
this issue
Oct 22, 2024
… Redshift Shares (#1643)⚠️ MERGE AFTER #1636 ### Feature or Bugfix - Feature: Testing ### Detail Add integration tests for Redshift shares. Implements #1620 - Implemented inside the shares modules in a subdirectory so that each share type can have its own conftest but still re-use common methods from shares queries - This PR is focused on testing the Redshift shares functionality, it does not include all tests that test the workflow of the share (e.g. submit, reject...) - It does not validate if after a share the user has access to data. We could implement it using the Redshift Data API, but I left it as optional for a separate PR ### Tested Locally:  ### Relates - #1620 - #1619 - #1220 ### Security Please answer the questions below briefly where applicable, or write `N/A`. Based on [OWASP 10](https://owasp.org/Top10/en/). - Does this PR introduce or modify any input fields or queries - this includes fetching data from storage outside the application (e.g. a database, an S3 bucket)? - Is the input sanitized? - What precautions are you taking before deserializing the data you consume? - Is injection prevented by parametrizing queries? - Have you ensured no `eval` or similar functions are used? - Does this PR introduce any functionality or component that requires authorization? - How have you ensured it respects the existing AuthN/AuthZ mechanisms? - Are you logging failed auth attempts? - Are you using or adding any cryptographic features? - Do you use a standard proven implementations? - Are the used keys controlled by the customer? Where are they stored? - Are you introducing any new policies/roles/users? - Have you used the least-privilege principle? How? By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Same as for #1220.
This issue is to track the progress for the Redshift Dataset module.
It has its own dedicated issue because of the challenge of validating the infrastructure of Redshift
The text was updated successfully, but these errors were encountered: