Update `forge-policy.json` to support least privilege

[ajfriedman18]

Currently, forge-policy.json is overly permissive in the controls it allocates to NF Tower. The current IAM policy applies * to a wide variety of API calls, which can inject potential vulnerabilities, such as in having permission to delete all EFS or FSx File systems, delete IAM roles, or access all S3 objects in an account.

Recommend scoping the IAM privileges down to specific ARNs/ARN patterns and updating the documentation to reflect principles of least privilege.

[pditommaso]

Hi, thanks for this feedback. Tower Forge can create (and therefore delete) EFS and FSx instances, this is why those permissions are added. Same for roles.

However, if you don't want or need to use these capabilities you can customise the policy by just removing that permission or narrowing down the scope of allowed resources.

[sjm446]

For a second opinion, it would be good to tighten the permissions up. I would suggest changing the * in the resources specification to something like *UID*, then drop a UID in the names of everything you create. Primarily it means users of Tower can't delete and modify resources they didn't create. I appreciate you will need some code tweaks as well.

[ajfriedman18]

Part of what would help is to break things out into separate statements to enable the appropriate granularity.

Would suggest at a start:

1. Allow for Create on the EFS and FSx file systems
2. Implement tagging with a defined Tag structure and restrict other permissions to those with the tags. Alternatively, can
3. Remove items like PassRole: * and instead scope them to only the roles/resources that need them.
4. Update the documentation with what you just mentioned.

Happy to collaborate on that with @sjm446 and others

[Bastian-Eisenmann]

Hi,
I have also seen that the policy contains permissions to create an AWS IAM role, attaching policies and also role assignment. With this combination a policy can be attached to an execution role which grants IAM* and with that it is able to grant full access to the whole AWS account.
For me this is an open backdoor if the credentials are abused. (Ofc I see no purpose why Sequerra should abuse that but the backdoor exist)
I Also have not seen an workaround by passing the roles manually in the "advanced" section area because here it is not possible to overwrite the "ServiceRole" which will be created by Sequera Platform - the other roles can be overwritten.
I would also recommend to put a side node regarding that into the documentation...

Regards