-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration tests executed on a real deployment as part of the CICD - Shares #1376
Comments
Required tests for basic coverageFor fresh deploymentsFor each of the following API calls we need to test authorized and unauthorized scenarios as well as all possible configurations (e.g. autoapproval...)
For backwards compatibilityFor updated Dataset stacks with existing shares validate:
Full coverage [WIP]For fresh deployments
For backwards compatibilityFor updated Dataset stacks:
|
Happy path tests: New Shares:
Persistent Shares:
|
Share 'breaks' tests:
|
Resource are missing test:
|
User Managed policy test:
|
### Feature or Bugfix - Tests ### Detail - module `share_base` - bugfix `delete_env` requires `env_object` not `envUri` - TEMPORARY: hardcoded dataset_uri --> I wait for dataset module ### Relates - #1376 ### 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. --------- Co-authored-by: dlpzx <[email protected]> Co-authored-by: Noah Paige <[email protected]> Co-authored-by: Sofia Sazonova <[email protected]>
### Feature or Bugfix - Feature ### Detail - test for persistent shares - common test functions are places in separate file - updated envs/dataset fixtures ### Relates - #1376 ### 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. --------- Co-authored-by: dlpzx <[email protected]> Co-authored-by: Noah Paige <[email protected]> Co-authored-by: Sofia Sazonova <[email protected]>
### Feature or Bugfix - Feature ### Detail New tests * deliberately break shares (by removing permissions * run the verifier to assert that are unhealthy * run the reapplier to assert that they can be fixed Imrpovements * Drop updated_persistent env and always update the persitent_env on get_or_create_env() * Use contextmanagers to create environments and handle their lifecycle in one place * Make redshift tests optional based on configuration ### Relates Solves parts of #1376 ### 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.
### Feature or Bugfix <!-- please choose --> - Feature ### Detail For group share and consumption role shares perform - [x] Create Share request - [x] Submit request without Items (not allowed) - [x] Add items to request - [x] Submit request - [x] Change request purpose - [x] Reject request - [x] Change reject purpose - [x] Approve request - [x] Request succeeded - [x] Item health verification - [x] Folder sharing validation (cal list objects via s3 accesspoint) - [x] Bucket sharing validation (cal list objects in s3 bucket ) - [x] Table sharing validation (cal perform athena query: select * from db.table ) - [x] Revoke items - [x] Folder sharing validation (no more access) - [x] Bucket sharing validation (no more access) - [x] Table sharing validation (no more access) - [x] Delete share Tests are the same as for new shares for new datasets Fixtures are parametrised ### Relates - #1376 ### 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. --------- Co-authored-by: Sofia Sazonova <[email protected]>
<!-- please choose --> - Feature For group share and consumption role shares perform - [x] Create Share request - [x] Submit request without Items (not allowed) - [x] Add items to request - [x] Submit request - [x] Change request purpose - [x] Reject request - [x] Change reject purpose - [x] Approve request - [x] Request succeeded - [x] Item health verification - [x] Folder sharing validation (cal list objects via s3 accesspoint) - [x] Bucket sharing validation (cal list objects in s3 bucket ) - [x] Table sharing validation (cal perform athena query: select * from db.table ) - [x] Revoke items - [x] Folder sharing validation (no more access) - [x] Bucket sharing validation (no more access) - [x] Table sharing validation (no more access) - [x] Delete share Tests are the same as for new shares for new datasets Fixtures are parametrised - #1376 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. --------- Co-authored-by: Sofia Sazonova <[email protected]>
Same as for #1220.
This issue is to track the progress for the Shares modules.
It has its own dedicated issue because of the challenge of validating the shares
The text was updated successfully, but these errors were encountered: