Jumpbox in its own Vnet #74
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
v-fearam
force-pushed
the
feature/move-jumpbox-ownvnet
branch
from
b0a3b53 to
584cdb9
Compare
v-fearam
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was working on the vnet-jumbox ticket.
The goods:
The bads. It was not able to create a private link/dns on the new vnet to access the cluster api. The current design use the FireWall as proxy DNS. There is a private dns on the hub vnet which resolve the current private ip for the cluster api.
Maintaining that design I’m not able to create a second private DNS against the same cluster api to resolve another private ip (the private endpoint in the new vnet). In the current design it must be on the hub vnet entering in conflict with the current one.
Now the traffic is allowed to move from the new Jumpbox vnet to the firewall, allowed in the firewall , and then moved to the cluster vnet private ip to access the cluster api.
The main image was not changed.