Enable VPC peering for Kyma clusters

[varbanv]

Description

Provide a way for end users to establish secure internal connectivity to other networks on the same hyperscaler via VPC peering.

Context

Problem

Currently, Kyma is a layer on top of Kubernetes and as such provides a very limited set of infrastructure configuration options at provisioning time. However, customers looking to adopt Kyma that already use existing hyperscaler offerings already take advantage of more advanced networking capabilities in order to establish secure internal connectivity to other workloads. Without such connectivity in Kyma, customers would require a much higher effort and increased risk tolerance in order to migrate or extend their existing workloads on Kyma.

Benefits

For customers:

• greater flexibility around infrastructure requirements
• ability to meet requirements in order to move workloads to Kyma
• reduced time to market for new development that requires secure and fast connectivity to existing workloads

For us:

• increase adoption
• mitigate the abandoned BYOC approach

Potential problems

• centralized network configuration management could complicate the implementation

Acceptance criteria

• [ ] Users can enable/disable VPC peering via Kyma Dashboard and command line
• [ ] Kyma will provide a mechanism for end users to access relevant information related to the VPC peering configuration
• [ ] The use of VPC peering will not require users to have direct access to the Kyma managed hyperscaler accounts
• [ ] Kyma will provide a reasonable solution for end users to monitor the state of the VPC peering setup

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.

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

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

[pbochynski]

The prototype has been started. Two repositories are created in kyma-project:

• https://github.com/kyma-project/cloud-resources-control-plane - the control plane part
• https://github.com/kyma-project/cloud-resources-manager - runtime operator

[ngrkajac]

For the sake of simplicity, we have moved all code to one repo. You can find all the code in the cloud-resources-manager repo now.

https://github.com/kyma-project/cloud-resources-manager - control plane, runtime operator

[github-actions[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[ngrkajac]

Status update

VPC Peering is under development.

We have a working MVP for VPC Peering on GCP. It's a happy path, but the "create" VPC Peering flow is working. We will finish VPC Peering creation for Azure soon, with AWS right after.

More info will arrive soon.

[github-actions[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[ngrkajac]

Status update: Development is done (mostly); we are in communication with the SRE team to add proper principals for every Cloud Provider.

[ngrkajac]

Dev is done, currently, this is being tested, and in a few days will be pushed to the stage.