Security group rule "Node Port Services" can be more restrictive

[vincepri]

When creating a new AWSCluster, part of the infrastructure is creating Security Groups for machines to use.

Currently, the Node Port Services security group allows access from any IP. Should we consider making this bit configurable to a set of pre-defined CIDR blocks, or allow the VPC CIDR's by default?

cluster-api-provider-aws/pkg/cloud/services/securitygroup/securitygroups.go

Lines 525 to 531 in 0eee277

	{
	Description: "Node Port Services",
	Protocol: infrav1.SecurityGroupProtocolTCP,
	FromPort: 30000,
	ToPort: 32767,
	CidrBlocks: []string{services.AnyIPv4CidrBlock},
	},

/area security
/kind bug
/assign @sedefsavas

[sedefsavas]

Yes, very good point.
SGs are opinionated and not very flexible other than supporting BYO SGs. Modifying existing SGs are not supported. Need to go through a refactoring, tracked here #392

Allowing only VPC CIDR by default will break some use cases (like peered VPC) without the flexibility to modify. So will address this as part of #392.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[rymancl]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[rymancl]

/remove-lifecycle stale