Dangerous/broad policy attached to ECS tasks

[r2bit]

We noticed a suspicious policy attached to cloud-connector ECS task role:

terraform-aws-secure-for-cloud/modules/services/cloud-connector/ecs-service-security.tf

Lines 106 to 121 in bdd8505

	resource "aws_iam_role_policy" "secrets_reader" {
	name = "SecretsReader"
	role = local.ecs_task_role_id
	policy = data.aws_iam_policy_document.secrets_reader.json
	}
	data "aws_iam_policy_document" "secrets_reader" {
	statement {
	effect = "Allow"
	actions = [
	"kms:Decrypt",
	"secretsmanager:GetSecretValue"
	]
	resources = ["*"]
	}
	}

Essentially granting access to all secrets in an account (or something close to that?).
Given the danger such policy poses, is there a specific reason that access is required by cloud-connector? Meanwhile, we're forced to use our own local copy of modules/services/cloud-connector which simply excludes the problematic blocks. :(

[wideawakening]

no reason at all, we've been pinning down permissions and this is one slipped; we can pin it down to the specific secret ecs is handling for cloud-connector.
will take care of it!

[wideawakening]

will try to push this soon, but if you wanna share your local changes, glad to merge the PR

[r2bit]

will try to push this soon, but if you wanna share your local changes, glad to merge the PR

What we did right now was simply remove that policy entirely. Since there actually is a secret ECS has to manage, I suggest you create a PR this time. We can help with next ones. ;)

[wideawakening]

What we did right now was simply remove that policy entirely. Since there actually is a secret ECS has to manage, I suggest you create a PR this time. We can help with next ones. ;)

umm but, if you removed policy, not sure how is it working (permission is required for task to fetch secret).
did you maybe provision specific permissions out of IAC or other way?

[r2bit]

What we did right now was simply remove that policy entirely. Since there actually is a secret ECS has to manage, I suggest you create a PR this time. We can help with next ones. ;)

umm but, if you removed policy, not sure how is it working (permission is required for task to fetch secret). did you maybe provision specific permissions out of IAC or other way?

As far as I know the token is stored in AWS System Manager (actions ssm:*) not AWS Secrets Manager (actions secretsmanager:*).

[wideawakening]

my bad meant

< permission is required for task to fetch secret
> permission for ecs task to be able to get/decrypt the cloudtrail-kms secret key

https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/blob/master/modules/infrastructure/cloudtrail/kms.tf

either-way, we should be able to pin it down to the specific

[r2bit]

my bad meant

< permission is required for task to fetch secret
> permission for ecs task to be able to get/decrypt the cloudtrail-kms secret key

https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/blob/master/modules/infrastructure/cloudtrail/kms.tf

either-way, we should be able to pin it down to the specific

Oh, sorry. We're using our existing CloudTrail. That's why it worked then, I guess.

[r2bit]

@wideawakening we ended up switching back to a local trail and I made a fix for the policy in our fork. I didn't create a PR here, since I'm not quite sure what's the purpose of having secretsmanager:* privileges.
You can see the last two commits here: https://github.com/salemove/terraform-aws-secure-for-cloud/tree/fix_kms_privileges. It's working w/o problems for us right now.

[wideawakening]

@r2bit we addressed this issue and you were right, we neither knew what secretmanager:*was required for.. sorry for those broad unnecessary privileges. more details in fixed PR.