MVC: Scan for public facing Amazon S3 buckets (#199820) · Issues · GitLab.org / GitLab

MVC: Scan for public facing Amazon S3 buckets

Problem to solve

When hosting applications, it is possible that cloud infrastructure becomes misconfigured and assets intended to be privately accessible unintentionally become publicly accessible. A common, specific example of this is when AWS S3 storage buckets that are incorrectly shared publicly.

Intended users

Further details

Proposal

Request a read-only token to the user's AWS cluster and identify S3 buckets that are publicly accessible. Provide a list of all public buckets back to the users in a report. Re-scan the given AWS cluster periodically (proposal: every hour) and update the results.

User journey

User goes to configuration screen
User enters AWS token, any other needed settings, and enables scanning
User views report page
User takes action based on results (such as deleting the S3 bucket or updating its permissions)
- We should guide the user to the relevant AWS page if possible but we don't need to fix their AWS statues from within GitLab for this issue

UX

Scanning should happen periodically without requiring a user to manually trigger the scan. Scanning should also not require a code commit nor an MR.
Report should live under a new section in Security & Compliance
Report should list each AWS S3 bucket that is publicly accessible and any relevant metadata.
- Coordinate with UX on designs for this screen. Sketch ideas in the Designs tab

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

GitLab Ultimate

Links / references

A lot of the technical challenges with this issue are similar to those solved in #36871 (closed) - consider how that issue resolved them as part of working this issue.

### Problem to solve

When hosting applications, it is possible that cloud infrastructure becomes misconfigured and assets intended to be privately accessible unintentionally become publicly accessible. A common, specific example of this is when AWS S3 storage buckets that are incorrectly shared publicly.

### Intended users

<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.

* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)

Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->

### Further details

### Proposal

#### User journey
1. User goes to configuration screen
1. User enters AWS token, any other needed settings, and enables scanning
1. User views report page
1. User takes action based on results (such as deleting the S3 bucket or updating its permissions)
   - We should guide the user to the relevant AWS page if possible but we don't need to fix their AWS statues from within GitLab for this issue

#### UX
1. Scanning should happen periodically without requiring a user to manually trigger the scan. Scanning should also not require a code commit nor an MR.
1. Report should live under a new section in Security & Compliance
1. Report should list each AWS S3 bucket that is publicly accessible and any relevant metadata.
   - _Coordinate with UX on designs for this screen. Sketch ideas in the Designs tab_

### Permissions and Security

### Documentation

### Availability & Testing

<!-- What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

### What does success look like, and how can we measure that?

### What is the type of buyer?

~"GitLab Ultimate"

### Links / references
A lot of the technical challenges with this issue are similar to those solved in #36871 - consider how that issue resolved them as part of working this issue.

Edited Feb 10, 2020 by Sam Kerr

Discussion
Designs