Get rid of eksctl produced cloud-user-sa

[yuvipanda]

The following three hubs use a cloud-user-sa service account provisioned by eksctl to give hub users full S3 access:

• uwhackweeks
• carbonplan
• openscapes

This predates our more modern terraform based service accounts. We should get rid of these eksctl generated accounts and bring these hubs in line with the rest.

Action items

Stop using the cloud-user-sa service account

• Stop using cloud-user-sa serviceaccount by removing jupyterhub.singleuser.serviceAccountName under config/clusters/openscapes/common.yaml. Make a PR, get this deployed.
• Test to make sure you can still access $SCRATCH_BUCKET S3 bucket, by running aws s3 ls $SCRATCH_BUCKET in a jupyterlab terminal in the hub. This should not error out.

Remove the IAM service account from AWS

• Render the .jsonnet file into a .yaml file with the jsonnet command in https://infrastructure.2i2c.org/hub-deployment-guide/new-cluster/aws/#create-and-render-an-eksctl-config-file
• Delete the iamserviceaccount with eksctl delete iamserviceaccount -f openscapes.eksctlyaml --name cloud-user-rsa
• Repeat the test from earlier to make sure that aws s3 ls $SCRATCH_BUCKET still works inside a terminal in the jupyterhub.
• Remove namespaces variable in eksctl/openscapes.jsonnet
• Remove iam.serviceAccounts in the main cluster definition in eksctl/opencsapes.jsonnet
• Make this into a PR, get it merged

Celebrate

This is a celebration of the fact that we've been serving openscapes so long that they're using deprecated features! When done, we can close this issue :)

[consideRatio]

uwhacksweeks is removed already via #2173, I opened #3291 to finalize the cleanup.

Related code

infrastructure/eksctl/carbonplan.jsonnet

Lines 70 to 82 in 682ef1f

	iam: {
	withOIDC: true,
	serviceAccounts: [{
	metadata: {
	name: "cloud-user-sa",
	namespace: namespace
	},
	attachPolicyARNs:[
	"arn:aws:iam::aws:policy/AmazonS3FullAccess"
	],
	} for namespace in namespaces],
	},

Issue scope question

@yuvipanda is the issue's scope narrowed specifically to replace how the permissions are granted? Currently carbonplan and openscapes has arn:aws:iam::aws:policy/AmazonS3FullAccess which includes permission for them to create their own buckets etc.

A wider scope could include:

• setup of scratch buckets
• reducing permissions granted (to not create/manage their own buckets, but only scratch buckets for example)

I suggest we avoid the expanded issue scope of also reducing permissions - as it requires community engagement as well, possibly making us blocked.

[yuvipanda]

@consideRatio makes sense to just have it be 'remove cloud-user-sa and replicate it in terraform`.

[GeorgianaElena]

makes sense to just have it be 'remove cloud-user-sa and replicate it in terraform`

@yuvipanda, by "replicate it in terraform", do you mean replicate the buckets in https://s3.console.aws.amazon.com/s3/buckets?region=us-east-1# for example (carbonplan) in the terraform config?

If so, I understand that the the service account that we create via terraform will not have full access to the buckets like the old cloud-user-sa. Is this correct?

Do we wish to retain such access for the existing buckets to not introduce a breaking change? If so, should extra_iam_policy be enough?

Also, @consideRatio said "arn:aws:iam::aws:policy/AmazonS3FullAccess which includes permission for them to create their own buckets etc." Do we wish to retain such permission in the future? Is this possible via our current terraform infra or do we need to tweak it to allow this.

I am trying to understand how complicated it would be to could get rid of cloud-user-sa together with #3224. Thank you!

[yuvipanda]

@GeorgianaElena yeah, we would have to communicate with the affected communities about it. Primary differences would be that they would not be able to create buckets, and there may be a change in how they can access buckets in other projects as well (am no sure).

I don't think this should be resolved along with #3224, that is a big enough project by itself I think.

[GeorgianaElena]

I don't think this should be resolved along with #3224, that is a big enough project by itself I think.

Ok, makes sense! Thanks @yuvipanda!

[yuvipanda]

This can just simply be removed, as they are currently not using this functionality at all.

[yuvipanda]

I've updated this issue with action items left to do very specifically.