Skip to content
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

Add MANAGE_SHARES permissions #1702

Merged
merged 4 commits into from
Nov 19, 2024
Merged

Conversation

dlpzx
Copy link
Contributor

@dlpzx dlpzx commented Nov 18, 2024

Feature or Bugfix

  • Feature

Detail

This PR introduces MANAGE_SHARES permission to enable data.all admins the ability to enable/disable shares permissions at the application-level.

The new permission would get created in the savepermissions Lambda trigger; but by default the permissions would be disabled for all existing groups in the platform. This would cause breaking changes and admins would need to enable this permission manually for each group. To avoid this, this PR includes a migration script that creates the permission and attaches it to existing groups.

Testing

  • Test migration script locally
  • Test migration script in CICD
  • Perform share mutations in real AWS deployment (approve share object, submit, add items) with tenant permissions
  • Perform share mutations in real AWS deployment (approve share object, submit, add items) WITHOUT tenant permissions (See screenshot)

image

Relates

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

  • 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 dlpzx mentioned this pull request Nov 18, 2024
@dlpzx dlpzx force-pushed the feat/add-tenant-permissions-shares branch from 3b64bea to f2110d0 Compare November 18, 2024 16:35
@dlpzx dlpzx requested a review from noah-paige November 18, 2024 16:52
@dlpzx dlpzx marked this pull request as ready for review November 18, 2024 17:31
@dlpzx dlpzx merged commit 64da618 into main Nov 19, 2024
9 checks passed
@dlpzx dlpzx deleted the feat/add-tenant-permissions-shares branch November 22, 2024 11:20
@dlpzx dlpzx mentioned this pull request Dec 4, 2024
dlpzx added a commit that referenced this pull request Dec 5, 2024
- Feature

This PR introduces `MANAGE_SHARES` permission to enable data.all admins
the ability to enable/disable shares permissions at the
application-level.

The new permission would get created in the savepermissions Lambda
trigger; but by default the permissions would be disabled for all
existing groups in the platform. This would cause breaking changes and
admins would need to enable this permission manually for each group. To
avoid this, this PR includes a migration script that creates the
permission and attaches it to existing groups.
- [x] Test migration script locally
- [x] Test migration script in CICD
- [x] Perform share mutations in real AWS deployment (approve share
object, submit, add items) with tenant permissions
- [x] Perform share mutations in real AWS deployment (approve share
object, submit, add items) WITHOUT tenant permissions (See screenshot)

![image](https://github.com/user-attachments/assets/961194a1-4e72-4399-8c20-f6962956ef8d)

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 dlpzx mentioned this pull request Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants