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

modules/*: trust CA certificates on the nodes #2362

Merged
merged 9 commits into from
Nov 22, 2017

Conversation

s-urbaniak
Copy link
Contributor

This also bumps the ignition provider to 1.0.0 to support S3 downloads
via ignition.

Fixes #INST-67

@coreosbot
Copy link

Can one of the admins verify this patch?

@s-urbaniak s-urbaniak changed the title [WIP] modules/*: trust CA certificates on the nodes modules/*: trust CA certificates on the nodes Nov 14, 2017
@s-urbaniak
Copy link
Contributor Author

@squat PTAL

Copy link
Contributor

@squat squat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great overall. I found one issue that I think breaks GCP. PTAL

@@ -3,6 +3,7 @@ data "ignition_config" "main" {
"${data.ignition_file.kubeconfig.id}",
"${var.ign_max_user_watches_id}",
"${var.ign_installer_kubelet_env_id}",
"${var.ign_ca_cert_id_list}",
]

systemd = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The worker is missing the var.ign_update_ca_certificates_dropin_id service

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed, thanks!

@@ -38,6 +38,11 @@ systemd:
- name: bootkube.service
enable: false
contents: {{.ign_bootkube_service_json}}
- name: update-ca-certificates.service
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not for this pr but we really need to refactor this platform so that it uses the same ignition format as all the other platforms

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

totally agreed 👍

@squat
Copy link
Contributor

squat commented Nov 17, 2017

ok to test

@s-urbaniak
Copy link
Contributor Author

This builds on top of #2421

@s-urbaniak
Copy link
Contributor Author

/cc @sym3tri @squat

this will need to slip unfortunately :-( despite the countermeasures in #2422 this exceeds the userdata limit on AWS. We need to move non-ciritical (security wise) assets to S3 to free up space in userdata unfortunately. This implies a larger refactoring though.

@s-urbaniak s-urbaniak changed the title modules/*: trust CA certificates on the nodes [WIP] modules/*: trust CA certificates on the nodes Nov 17, 2017
Sergiusz Urbaniak added 9 commits November 21, 2017 12:20
This also bumps the ignition provider to 1.0.0 to support S3 downloads
via ignition.

Fixes #INST-67
Currently etcd certificate ignition files are created in their
respective platform module.

This unifies it by declaring the ignition file units centrally in the
ignition module.
Currently the etcd TLS module also generates a zip file which is only
used on AWS to reduce the userdata size to be <20k (hard limit on AWS).

Since the etcd TLS assets will be provisioned via S3 this optimization/hack
is not needed any more.
We hit the limits of the AWS userdata limit (20k) constantly.

This fixes it by provisioning a minimal ignition configuration only
which points to a replacement ignition configuration hosted on S3.

This also removes workarounds/hacks to keep the userdata size small,
especially for provisioning TLS assets on etcd nodes.
@s-urbaniak s-urbaniak changed the title [WIP] modules/*: trust CA certificates on the nodes modules/*: trust CA certificates on the nodes Nov 21, 2017
@s-urbaniak
Copy link
Contributor Author

@squat @enxebre PTAL

@s-urbaniak
Copy link
Contributor Author

retest this please

Copy link
Contributor

@squat squat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM once green


[Service]
ExecStart=
ExecStart=/usr/sbin/update-ca-certificates
Copy link
Contributor Author

@s-urbaniak s-urbaniak Nov 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/cc @lucab This works, because we are enforcing rehashing all files. Rather the default service should work, but openssl is pointing to the wrong default bundle.

@s-urbaniak
Copy link
Contributor Author

all green, merging

@s-urbaniak s-urbaniak merged commit 0c7ac90 into coreos:master Nov 22, 2017
"Action": [
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@s-urbaniak Why did you need to add ECR permissions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might've been a copy&pasta oversight, but without this the machine didn't seem to boot.

enxebre pushed a commit to enxebre/tectonic-installer that referenced this pull request Dec 18, 2017
* modules/*: trust CA certificates on the nodes

This also bumps the ignition provider to 1.0.0 to support S3 downloads
via ignition.

Fixes #INST-67

* modules/ignition: unify etcd certificate generation

Currently etcd certificate ignition files are created in their
respective platform module.

This unifies it by declaring the ignition file units centrally in the
ignition module.

* modules/tls/etcd: remove zip generation

Currently the etcd TLS module also generates a zip file which is only
used on AWS to reduce the userdata size to be <20k (hard limit on AWS).

Since the etcd TLS assets will be provisioned via S3 this optimization/hack
is not needed any more.

* */aws: use S3 for ignition provisioning

We hit the limits of the AWS userdata limit (20k) constantly.

This fixes it by provisioning a minimal ignition configuration only
which points to a replacement ignition configuration hosted on S3.

This also removes workarounds/hacks to keep the userdata size small,
especially for provisioning TLS assets on etcd nodes.

* Documentation/examples: regenerate

* */azure: use unified etcd TLS ignition files

* */gcp: use unified etcd TLS ignition files

* */openstack: use unified etcd TLS ignition files

* */vmware: use unified etcd TLS ignition files
enxebre pushed a commit to enxebre/tectonic-installer that referenced this pull request Dec 19, 2017
* modules/*: trust CA certificates on the nodes

This also bumps the ignition provider to 1.0.0 to support S3 downloads
via ignition.

Fixes #INST-67

* modules/ignition: unify etcd certificate generation

Currently etcd certificate ignition files are created in their
respective platform module.

This unifies it by declaring the ignition file units centrally in the
ignition module.

* modules/tls/etcd: remove zip generation

Currently the etcd TLS module also generates a zip file which is only
used on AWS to reduce the userdata size to be <20k (hard limit on AWS).

Since the etcd TLS assets will be provisioned via S3 this optimization/hack
is not needed any more.

* */aws: use S3 for ignition provisioning

We hit the limits of the AWS userdata limit (20k) constantly.

This fixes it by provisioning a minimal ignition configuration only
which points to a replacement ignition configuration hosted on S3.

This also removes workarounds/hacks to keep the userdata size small,
especially for provisioning TLS assets on etcd nodes.

* Documentation/examples: regenerate

* */azure: use unified etcd TLS ignition files

* */gcp: use unified etcd TLS ignition files

* */openstack: use unified etcd TLS ignition files

* */vmware: use unified etcd TLS ignition files
@enxebre enxebre mentioned this pull request Dec 19, 2017
@@ -0,0 +1,25 @@
resource "aws_s3_bucket_object" "ignition_etcd" {
count = "${length(var.external_endpoints) == 0 ? var.instance_count : 0}"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm new to Terraform and was scratching my head about this after not finding count in the aws_s3_bucket_object docs. It turns out it is a meta-parameter (more here). I thought I'd add this note in case it helps any other Terraform newbies ;).

wking added a commit to wking/openshift-installer that referenced this pull request Jul 23, 2018
The local variable is from cd71f30 (Ignition assets, 2018-02-14,
coreos/tectonic-installer#2940), but it doesn't scale beyond three
etcd nodes.  This commit pivots to an approach that scales to an
arbitrary number of nodes, matching the scalable generation logic
we've had since 0c7ac90 (modules/*: trust CA certificates on the
nodes, 2017-11-22, coreos/tectonic-installer#2362).
yifan-gu pushed a commit to yifan-gu/installer that referenced this pull request Jul 25, 2018
The local variable is from cd71f30 (Ignition assets, 2018-02-14,
coreos/tectonic-installer#2940), but it doesn't scale beyond three
etcd nodes.  This commit pivots to an approach that scales to an
arbitrary number of nodes, matching the scalable generation logic
we've had since 0c7ac90 (modules/*: trust CA certificates on the
nodes, 2017-11-22, coreos/tectonic-installer#2362).
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants