Cluster-api-provider-aws: Support existing VPC infrastructure

Created on 17 Oct 2018  Â·  5Comments  Â·  Source: kubernetes-sigs/cluster-api-provider-aws

/kind feature

Currently we only support creating infrastructure on demand, we also need to support users bringing existing infrastructure.

/priority important-soon
/assign @randomvariable

kinfeature lifecyclactive prioritimportant-longterm

Most helpful comment

@timothysc @vincepri

Based on my experience, I believe the primary requirement is to stay hands-off anything in the networking space. This would include:

  • VPC
  • Subnets
  • Route Tables
  • Security Groups
  • NAT / Internet Gateway

The idea being the operator supplies VPC and subnets, which the AWS provider then places its things inside of. This does put the onus on the network administrator to set things up correctly. It’d be to eventually validate things like “Based on your existing SG rules, this port won’t be open and will break X”. However, I personally don’t think it’s essential and an OK expectation for the network administrator(s) to not shoot themselves in the foot.

There are several in between usecases where the provider does partial management (e.g. security groups and route tables only) but I think you’ll end up with several variations of what managed means. I also believe the initial use case above is what most folks who are very restricted in their VPC design will need to get started.

Is the above helpful?

All 5 comments

@joshrosso @rosskukulinski
We really need some user requirements for this issue

/lifecycle active

@timothysc @vincepri

Based on my experience, I believe the primary requirement is to stay hands-off anything in the networking space. This would include:

  • VPC
  • Subnets
  • Route Tables
  • Security Groups
  • NAT / Internet Gateway

The idea being the operator supplies VPC and subnets, which the AWS provider then places its things inside of. This does put the onus on the network administrator to set things up correctly. It’d be to eventually validate things like “Based on your existing SG rules, this port won’t be open and will break X”. However, I personally don’t think it’s essential and an OK expectation for the network administrator(s) to not shoot themselves in the foot.

There are several in between usecases where the provider does partial management (e.g. security groups and route tables only) but I think you’ll end up with several variations of what managed means. I also believe the initial use case above is what most folks who are very restricted in their VPC design will need to get started.

Is the above helpful?

+1 to @joshrosso's assessment. This is most what we had to support in Tectonic (for context).

Some text somewhere along the lines of "Ensure your cloud/network administrator has followed this checklist (link) / opened the required ports (link) on the relevant security groups." would get us most of the way in lieu of actual programmatic validation.

@joshrosso @justaugustus Thanks for the insights and extended context! Started some of this work in #483 which matches the BYON concept with added validation in a few steps. One thing that was brought up were read permissions. Currently we try to describe network resources to make sure they pass some validation and to populate the internal status objects.

Was this page helpful?
0 / 5 - 0 ratings