[WIP] update suggestions for add features in aws mutlti zone support

[cclhsu]

update suggestions from code review for add features in aws mutlti zone support

Signed-off-by: cclhsu [email protected]

Why is this PR needed?

Does it fix an issue? addresses a business case?

add a description and link to the issue if one exists.

Fixes #

Reminder: Add the "fixes bsc#XXXX" to the title of the commit so that it will
appear in the changelog.

What does this PR do?

please include a brief "management" technical overview (details are in the code)

Anything else a reviewer needs to know?

Special test cases, manual steps, links to resources or anything else that could be helpful to the reviewer.

Info for QA

This is info for QA so that they can validate this. This is mandatory if this PR fixes a bug.
If this is a new feature, a good description in "What does this PR do" may be enough.

Related info

Info that can be relevant for QA:

• link to other PRs that should be merged together
• link to packages that should be released together
• upstream issues

Status BEFORE applying the patch

How can we reproduce the issue? How can we see this issue? Please provide the steps and the prove
this issue is not fixed.

Status AFTER applying the patch

How can we validate this issue is fixed? Please provide the steps and the prove this issue is fixed.

Docs

If docs need to be updated, please add a link to a PR to https://github.com/SUSE/doc-caasp.
At the time of creating the issue, this PR can be work in progress (set its title to [WIP]),
but the documentation needs to be finalized before the PR can be merged.

Merge restrictions

(Please do not edit this)

We are in v4-maintenance phase, so we will restrict what can be merged to prevent unexpected surprises:

What can be merged (merge criteria):
    2 approvals:
        1 developer: code is fine
        1 QA: QA is fine
    there is a PR for updating documentation (or a statement that this is not needed)

[Klaven]

Hey, Looked over the PR a little bit this morning, had a few quick questions regarding it.

1. could you fill out the PR template a bit more? While i'm a bit fan of "the code should speak for itself" a lot of the time the code does not give a good "why" and that would be helpful!

2. the PR is quite large :D anything you could do to slim it down would make it easier to review

3. generally, I don't think the API server should be exposed externally unless someone absolutely needs it... and lets be honest, no one actually needs it. A large part of the security CVE's can be mitigated by keeping the control plane safe.

[Klaven]

Same here, Api server should be internal only as well.

[cclhsu]

var.cidr_block is internal.

[Klaven]

@dannysauer Correct me if i'm wrong but I don't think we should expose the API server too the web. this is an easy first step to securing them, making it so that only inside the cluster can directly hit the api server. I would be for removing this block.

[dannysauer]

I'm not completely clear why we open 80/443 to begin with; nothing listens on those ports by default, right? Was that just a copy-paste from an example that was left behind all along?

[dannysauer]

Also, yes, exposing the api server seems undesirable. I guess it's possible to control access to the whole vpc and that might be an acceptable control, but I honestly haven't read the entire config to see if that's being done. It still seems like it'd be preferable to elect a source IP as "management node" or identify a management network.

[cclhsu]

This is from original code. I just try to rearrange code by function. I will test to remove 80/443 to see if any side effect

[cclhsu]

Hey, Looked over the PR a little bit this morning, had a few quick questions regarding it.

1. could you fill out the PR template a bit more? While i'm a bit fan of "the code should speak for itself" a lot of the time the code does not give a good "why" and that would be helpful!
2. the PR is quite large :D anything you could do to slim it down would make it easier to review
3. generally, I don't think the API server should be exposed externally unless someone absolutely needs it... and lets be honest, no one actually needs it. A large part of the security CVE's can be mitigated by keeping the control plane safe.

Ok, I will slim PR down to focus just multiple zone. I am add too many formatting change and little customized improvemnt here and there.

[Klaven]

From my point of view this looks fine. I don't know enough about our AWS deployment to say though. @flavio would be a good reviewer.

[dannysauer]

I'm in the same boat as @Klaven ; this looks fine to me as a cleanup, but I don't have enough "AWS via Terraform" background to say it's good to go.