AWS Access for Malicious Packages

[kj-powell]

Hi TAC,

The Malicious Packages repo needs AWS access to create an IAM role. We've been working with IT to find a solution to this, and the easiest way would be to give them the keys to AWS. IT mentioned that while they typically don't recommend this route, there are other communities who do it. The alternative would be for the OpenSSF to pay IT to manage our AWS account, but the smallest tier they offer is still quite expensive.

I'm opening this issue to get everyone's thoughts on this. Is sharing the AWS key with Malicious Packages something the TAC would be comfortable with?

[mlieberman85]

Which AWS account? Is this AWS account specific to the Malicious Packages project?

[calebbrown]

For context this is for https://github.com/ossf/malicious-packages/issues/935

My plan is to have an IAM role whose ID can be used by malicious report sources to provide access to their AWS S3 buckets.

To protect the account I would ideally use OIDC to handle the authentication with AWS from our GitHub workflow (instead of a long-lived secret).

[steiza]

At risk of over-explaining, here's what I think is being proposed:

• Create a new, highly privileged, IAM User in OpenSSF's AWS account
• Give the credentials for that IAM User to whoever is working on https://github.com/ossf/malicious-packages/issues/935
• They will log in as that IAM User, create an IAM Role, trust relationship, and configure S3 buckets
• They will test that the IAM Role, trust relationship, and S3 bucket is working as expected
• We will delete the highly privileged IAM User

If so, that sounds like a reasonable plan to me.

[marcelamelara]

To protect the account I would ideally use OIDC to handle the authentication with AWS from our GitHub workflow (instead of a long-lived secret).

This makes more sense to me than handing over keys directly. Am I right in assuming that this is a workflow you'll be running repeatedly (so, deleting the IAM user isn't possible)?

[steiza]

Ah, sorry, to clarify, I was suggesting creating a temporary IAM User with privileges in order to set up the IAM Role, trust relationship, and S3 bucket configuration, after which the IAM User would be deleted.

The IAM Role (etc) would remain, and that is what the workflow would use whenever it runs.

[kj-powell]

Thanks everyone for your feedback! Would it be okay to give Caleb the keys for now so we can unblock this issue, and start working on a longer term solution and documentation for when situations like this arise?

[steiza]

Thanks everyone for your feedback! Would it be okay to give Caleb the keys for now so we can unblock this issue, and start working on a longer term solution and documentation for when situations like this arise?

Yes please, and thanks! When Caleb has the IAM role and S3 bucket configured, let's be sure to delete the temporary IAM user that was used to configure those things interactively.

[kj-powell]

@calebbrown see comment above. @steiza thank you! I'll work with IT to get Caleb's access set up.

[calebbrown]

Hi, just wondering where this is up to. Thanks! @kj-powell

[kj-powell]

Sorry Caleb- I was out of the office. You will need to make an LFX profile (I just sent you the link via Slack). Once that's done, IT will grant you AWS access.