Deployment results in internal security flag

[SPlanzer]

The design of this repository is becoming increasingly in conflict with internal security checks. Deploying this code base now results in IT being notified and very quickly getting in touch (see automated messaging below).

I assume this check is to ensure we do not release any sensitive information. This design was purposely open to allow LINZ users to have easy access to plugins but also to potentially share access to LINZ specific plugins with users outside LINZ.

Options going froward include:

• Remove public access and investigate how to best manage access
• Keep triggering calls from LINZ and work with them to resolve this state.

GuardDuty Finding | xxxxxxxxx | Account: XXXXXXXXXXXXXXXX
Finding type: Policy:S3/BucketAnonymousAccessGranted
The Amazon S3 bucket xxxxxxxx was granted public anonymous access by AccountAdminRole calling PutBucketPolicy. If this behavior is not expected, it may indicate a configuration mistake or that your credentials are compromised.
First Seen
Wed, 30 Mar 2022 22:39:47 GMT
Last Seen
Wed, 30 Mar 2022 22:39:47 GMT
Severity
HIGH
Threat Count
1

[SPlanzer]

Hi @ShawnO12 (FYI @billgeo )

This application was designed to have an s3 bucket with a policy that solely allows PublicGetObj (writing via a Lambda based API).

It is suggested we add a suppression rule in GuardDuty to allow public get on this bucket (as well as the prd bucket)
I will send you the account and bucket details we would like the suppression against.

There will also time to time be deployments of other temporary test/development version for dev/testing, that will create temporary buckets with these settings, do we just live with the alarms on these?

[SPlanzer]

The two accounts affected are li-small-app-nonprod and li-small-apps-prod

Im am unsure how GuardDuty is configured but can we have the rule suppressed for buckets in a regex fashion == qgis-plugin-repo-.*