Skip to content
This repository has been archived by the owner on Feb 5, 2020. It is now read-only.

WIP OpenStack prototype #1

Merged
merged 1 commit into from
Feb 17, 2017
Merged

WIP OpenStack prototype #1

merged 1 commit into from
Feb 17, 2017

Conversation

alexsomesan
Copy link
Contributor

  • nodes provisioned via userdata
  • master kubelet configured and stating
  • bootkube systemd unit provisioned

* nodes provisioned via userdata
* master kubelet configured and stating
* bootkube systemd unit provisioned
@alexsomesan alexsomesan merged commit 73ec9ed into coreos:master Feb 17, 2017
nreisbeck referenced this pull request in nreisbeck/tectonic-installer Oct 19, 2017
Updates to support etcd nodes on Digital Ocean
trawler added a commit that referenced this pull request Jan 17, 2018
Add missing local var for http proxy enablement
abhinavdahiya pushed a commit to abhinavdahiya/tectonic-installer that referenced this pull request Mar 29, 2018
wking added a commit to wking/openshift-installer that referenced this pull request Sep 26, 2019
And in the UPI CloudFormation templates too.

We've allowed ICMP ingress for OpenStack since 6f76298 (OpenStack
prototype, 2017-02-16, coreos/tectonic-installer#1), which did not
motivate the ICMP ingress.  Allowing ICMP ingress for AWS dates back
to b620c16 (modules/aws: tighten security groups, 2017-04-19,
coreos/tectonic-installer#264).  The master rule was restricted to the
VPC in e7bd29a (modules/aws/vpc - Better security for master nodes,
2017-10-16, coreos/tectonic-installer#2147).  And the worker rules was
restricted to the VPC in e131a74 (aws: fix ICMP ACL, 2019-04-08,
in-cluster ICMP ingress.

There are reasons to allow in-cluster ICMP, including Path MTU
Discovery (PMTUD) [1,2,3].  Folks also use ping to troubleshoot
connectivity [4].  Restricting this to in-cluster security groups will
avoid exposing ICMP ports to siblings living in shared VPCs, as we
move towards allowing the installer to launch clusters in a
pre-existing VPC.  It might also block ICMP ingress from our load
balancers, where we probably want PMTUD and possibly other ICMP calls.
I'm not sure if there's a convenient way to allow access from the
load-balancers while excluding it from sibling clusters that share the
same VPC, but this commit is my attempt to get that.

[1]: http://shouldiblockicmp.com/
[2]: https://tools.ietf.org/html/rfc1191
[3]: https://tools.ietf.org/html/rfc8201
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1689857#c2
wking added a commit to wking/openshift-installer that referenced this pull request Sep 26, 2019
And in the UPI CloudFormation templates too.

We've allowed ICMP ingress for OpenStack since 6f76298 (OpenStack
prototype, 2017-02-16, coreos/tectonic-installer#1), which did not
motivate the ICMP ingress.  Allowing ICMP ingress for AWS dates back
to b620c16 (modules/aws: tighten security groups, 2017-04-19,
coreos/tectonic-installer#264).  The master rule was restricted to the
VPC in e7bd29a (modules/aws/vpc - Better security for master nodes,
2017-10-16, coreos/tectonic-installer#2147).  And the worker rules was
restricted to the VPC in e131a74 (aws: fix ICMP ACL, 2019-04-08, openshift#1550),
before which a typo had blocked all ICMP ingress.

There are reasons to allow in-cluster ICMP, including Path MTU
Discovery (PMTUD) [1,2,3].  Folks also use ping to troubleshoot
connectivity [4].  Restricting this to in-cluster security groups will
avoid exposing ICMP ports to siblings living in shared VPCs, as we
move towards allowing the installer to launch clusters in a
pre-existing VPC.  It might also block ICMP ingress from our load
balancers, where we probably want PMTUD and possibly other ICMP calls.
I'm not sure if there's a convenient way to allow access from the
load-balancers while excluding it from sibling clusters that share the
same VPC, but this commit is my attempt to get that.

[1]: http://shouldiblockicmp.com/
[2]: https://tools.ietf.org/html/rfc1191
[3]: https://tools.ietf.org/html/rfc8201
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1689857#c2
wking added a commit to wking/openshift-installer that referenced this pull request Sep 26, 2019
And in the UPI CloudFormation templates too.

We've allowed ICMP ingress for OpenStack since 6f76298 (OpenStack
prototype, 2017-02-16, coreos/tectonic-installer#1), which did not
motivate the ICMP ingress.  Allowing ICMP ingress for AWS dates back
to b620c16 (modules/aws: tighten security groups, 2017-04-19,
coreos/tectonic-installer#264).  The master rule was restricted to the
VPC in e7bd29a (modules/aws/vpc - Better security for master nodes,
2017-10-16, coreos/tectonic-installer#2147).  And the worker rules was
restricted to the VPC in e131a74 (aws: fix ICMP ACL, 2019-04-08, openshift#1550),
before which a typo had blocked all ICMP ingress.

There are reasons to allow in-cluster ICMP, including Path MTU
Discovery (PMTUD) [1,2,3].  Folks also use ping to troubleshoot
connectivity [4].  Restricting this to in-cluster security groups will
avoid exposing ICMP ports to siblings living in shared VPCs, as we
move towards allowing the installer to launch clusters in a
pre-existing VPC.  It might also block ICMP ingress from our load
balancers, where we probably want PMTUD and possibly other ICMP calls.
I'm not sure if there's a convenient way to allow access from the
load-balancers while excluding it from sibling clusters that share the
same VPC, but this commit is my attempt to get that.

[1]: http://shouldiblockicmp.com/
[2]: https://tools.ietf.org/html/rfc1191
[3]: https://tools.ietf.org/html/rfc8201
[4]: https://bugzilla.redhat.com/show_bug.cgi?id=1689857#c2
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant