Add CA certificate bundle distributor to conduit install #675

klingerf · 2018-04-04T20:00:06Z

This branch adds another controller command that runs a kubernetes controller that distributes the conduit-ca-bundle configmap from the conduit namespace to all namespaces where a conduit proxy is running. The controller implementation is loosely based on @jbeda's tgik-controller project.

I've updated the conduit install output to run the distributor as a separate deployment in the conduit namespace. As it is currently implemented, all pod specs in the install output are injected with a conduit-proxy sidecar, including this one. Since the distributor pod does not accept inbound traffic, it probably doesn't need to be injected. But it does make outbound calls to the kubernetes api, in which case it might be useful to route those calls through the proxy. We can remove it in the future if we feel like that's unnecessary.

Fixes #309.

oivindoh · 2018-04-27T15:50:32Z

Ridiculously eagerly awaiting this feature. Thanks for the great work!

klingerf · 2018-06-06T03:00:18Z

I'm planning on updating this branch to leverage the changes from #1072 once that pull request merges.

siggy · 2018-06-14T20:04:46Z

controller/cmd/ca-distributor/main.go

+	log "github.com/sirupsen/logrus"
+)
+
+const configMapName = "conduit-ca-bundle"


this is unused and redundant with CertificateBundleName?

siggy · 2018-06-14T20:08:06Z

cli/install/template.go

@@ -34,7 +34,6 @@ kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1beta1
 metadata:
  name: conduit-controller
-  namespace: {{.Namespace}}


what's motivation for removal of namespace:?

It turns out ClusterRoleBinding resources aren't namespaced, so including one is a bit deceiving, since it has no effect. I realized this while adding the conduit-ca binding, and decided to update it everywhere.

siggy · 2018-06-14T20:21:46Z

cli/install/template.go

+        - "-controller-namespace={{.Namespace}}"
+        - "-log-level={{.ControllerLogLevel}}"
+        - "-logtostderr=true"
+


extra line?

siggy · 2018-06-14T20:22:44Z

controller/ca/controller.go

+		namespace: conduitNamespace,
+		k8sAPI:    k8sAPI,
+		queue: workqueue.NewNamedRateLimitingQueue(
+			workqueue.DefaultControllerRateLimiter(), "certificates"),


siggy · 2018-06-14T20:26:54Z

controller/ca/controller.go

+}
+
+func (c *CertificateController) handleConfigMapAdd(obj interface{}) {
+	cm := obj.(*v1.ConfigMap)


other places are doing something like:

cm, ok := obj.(*v1.ConfigMap) if !ok {

...any reason not to do that here?

I can't seem to find it written out explicitly anywhere, but the add and update funcs always receive an object, so it's safe to cast them without checking to make sure the cast succeeded. The delete func can receive a tombstone, in which case you have to have the check. From the cache docs:

* OnAdd is called when an object is added. * OnUpdate is called when an object is modified. Note that oldObj is the last known state of the object-- it is possible that several changes were combined together, so you can't use this to see every single change. OnUpdate is also called when a re-list happens, and it will get called even if nothing changed. This is useful for periodically evaluating or syncing something. * OnDelete will get the final state of the item if it is known, otherwise it will get an object of type DeletedFinalStateUnknown. This can happen if the watch is closed and misses the delete event and we don't notice the deletion until the subsequent re-list.

This convention also appears to be prevalent in the kubernetes code base. For instance, in the controller that I previously linked to, I see:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/certificates/certificate_controller.go#L74

siggy · 2018-06-14T20:36:52Z

controller/ca/controller.go

+	log.Info("starting certificate controller")
+	defer log.Info("shutting down certificate controller")
+
+	go wait.Until(c.worker, time.Second, stopCh)


curious at the interaction between wait.Until and processNextWorkItem.

from https://godoc.org/k8s.io/apimachinery/pkg/util/wait#Until:
Until loops until stop channel is closed, running f every period.

the implementation of worker() calls c.queue.Get() in a for loop. from https://godoc.org/k8s.io/client-go/util/workqueue#Type.Get:
Get blocks until it can return an item to be processed.

wouldn't worker() run forever on its own, without the need for wait.Until wrapping it?

Hmm, yeah, this is a great question! I assumed that the main benefit of using wait.Until here was to be able to stop the worker by closing stopCh, but I think you're right that if the worker loops forever without returning, then closing the channel won't actually stop it.

I guess another possibility is that the worker process could exit in some other way (a panic, I suppose), and wait.Until would restart it. At least, this comment from tgik-controller seems to indicate that that's a possibility:

// runWorker will loop until "something bad" happens. wait.Until will // then rekick the worker after one second.

But, looking at the implementation of wait.Until, it doesn't actually recover from panic, so ¯\(ツ)/¯

FWIW, this pattern seems to be all over the kubernetes codebase. For instance:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/certificates/certificate_controller.go#L121

So I'm inclined to use it here as well, even though we can't figure out what it's actually doing for us :-/

siggy · 2018-06-14T20:41:39Z

controller/ca/controller.go

+	if apierrors.IsNotFound(err) {
+		log.Warnf("configmap [%s] not found in namespace [%s]",
+			pkgK8s.CertificateBundleName, c.namespace)
+		return nil


curious why we want to swallow this error?

related, i'm seeing these warning in the logs, expected?

time="2018-06-14T20:21:48Z" level=warning msg="configmap [conduit-ca-bundle] not found in namespace [conduit]" time="2018-06-14T20:31:48Z" level=warning msg="configmap [conduit-ca-bundle] not found in namespace [conduit]" time="2018-06-14T20:31:48Z" level=warning msg="configmap [conduit-ca-bundle] not found in namespace [conduit]" time="2018-06-14T20:41:47Z" level=warning msg="configmap [conduit-ca-bundle] not found in namespace [conduit]" time="2018-06-14T20:51:46Z" level=warning msg="configmap [conduit-ca-bundle] not found in namespace [conduit]"

probably related, i'm not seeing any configmaps getting created, am i missing someting?

$ kubectl --all-namespaces=true get cm NAMESPACE NAME DATA AGE conduit grafana-config 3 52m conduit prometheus-config 1 52m kube-public cluster-info 2 2d kube-system extension-apiserver-authentication 6 2d kube-system kube-proxy 2 2d kube-system kubeadm-config 1 2d

Right, this branch only includes a process for distributing the certificate, if it already exists. There will be a separate branch and separate process for creating the certificate on install. So it's ok for this process to loop indefinitely waiting for the certificate to be created, but I still wanted an indication in the logs that that's what it's doing.

For local testing, I've just been manually creating an empty config map, with:

kubectl -n conduit create cm conduit-ca-bundle

Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

…ontroller Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

klingerf

@siggy Thanks for the super thorough review!

klingerf · 2018-06-14T21:15:35Z

cli/install/template.go

@@ -34,7 +34,6 @@ kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1beta1
 metadata:
  name: conduit-controller
-  namespace: {{.Namespace}}


It turns out ClusterRoleBinding resources aren't namespaced, so including one is a bit deceiving, since it has no effect. I realized this while adding the conduit-ca binding, and decided to update it everywhere.

klingerf · 2018-06-14T21:53:03Z

controller/ca/controller.go

+	log.Info("starting certificate controller")
+	defer log.Info("shutting down certificate controller")
+
+	go wait.Until(c.worker, time.Second, stopCh)


Hmm, yeah, this is a great question! I assumed that the main benefit of using wait.Until here was to be able to stop the worker by closing stopCh, but I think you're right that if the worker loops forever without returning, then closing the channel won't actually stop it.

I guess another possibility is that the worker process could exit in some other way (a panic, I suppose), and wait.Until would restart it. At least, this comment from tgik-controller seems to indicate that that's a possibility:

// runWorker will loop until "something bad" happens. wait.Until will // then rekick the worker after one second.

But, looking at the implementation of wait.Until, it doesn't actually recover from panic, so ¯\(ツ)/¯

FWIW, this pattern seems to be all over the kubernetes codebase. For instance:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/certificates/certificate_controller.go#L121

So I'm inclined to use it here as well, even though we can't figure out what it's actually doing for us :-/

klingerf · 2018-06-14T21:57:22Z

controller/ca/controller.go

+	if apierrors.IsNotFound(err) {
+		log.Warnf("configmap [%s] not found in namespace [%s]",
+			pkgK8s.CertificateBundleName, c.namespace)
+		return nil


Right, this branch only includes a process for distributing the certificate, if it already exists. There will be a separate branch and separate process for creating the certificate on install. So it's ok for this process to loop indefinitely waiting for the certificate to be created, but I still wanted an indication in the logs that that's what it's doing.

For local testing, I've just been manually creating an empty config map, with:

kubectl -n conduit create cm conduit-ca-bundle

klingerf · 2018-06-14T22:05:41Z

controller/ca/controller.go

+}
+
+func (c *CertificateController) handleConfigMapAdd(obj interface{}) {
+	cm := obj.(*v1.ConfigMap)


I can't seem to find it written out explicitly anywhere, but the add and update funcs always receive an object, so it's safe to cast them without checking to make sure the cast succeeded. The delete func can receive a tombstone, in which case you have to have the check. From the cache docs:

* OnAdd is called when an object is added. * OnUpdate is called when an object is modified. Note that oldObj is the last known state of the object-- it is possible that several changes were combined together, so you can't use this to see every single change. OnUpdate is also called when a re-list happens, and it will get called even if nothing changed. This is useful for periodically evaluating or syncing something. * OnDelete will get the final state of the item if it is known, otherwise it will get an object of type DeletedFinalStateUnknown. This can happen if the watch is closed and misses the delete event and we don't notice the deletion until the subsequent re-list.

This convention also appears to be prevalent in the kubernetes code base. For instance, in the controller that I previously linked to, I see:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/certificates/certificate_controller.go#L74

siggy

works!

rmars

⭐️ 🐑 niceeee!

$ kubectl get configmaps --all-namespaces
NAMESPACE     NAME                                 DATA      AGE
conduit       conduit-ca-bundle                    0         7s
conduit       grafana-config                       3         3d
conduit       prometheus-config                    1         3d
emojivoto     conduit-ca-bundle                    0         7s
kube-public   cluster-info                         1         6d
kube-system   extension-apiserver-authentication   6         6d
kube-system   kube-proxy                           2         6d
kube-system   kubeadm-config                       1         6d

@briansmith

* Propagate errors in conduit containers to the api (#1117) - It would be nice to display container errors in the UI. This PR gets the pod's container statuses and returns them in the public api - Also add a terminationMessagePolicy to conduit's inject so that we can capture the proxy's error messages if it terminates * proxy: Update prost to 0.4.0 (#1127) prost-0.4.0 has been released, which removes unnecessary dependencies. tower-grpc is being updated simultaneously, as this is the proxy's primary use of prost. See: https://github.com/danburkert/prost/releases/tag/v0.4.0 * Simplify & clarify "No TLS" server configuration (#1131) The same pattern will be used for the "No TLS" client configuration. Signed-off-by: Brian Smith <brian@briansmith.org> * proxy: Fix Inotify falling back to polling when files don't exist yet (#1119) This PR changes the proxy's Inotify watch code to avoid always falling back to polling the filesystem when the watched files don't exist yet. It also contains some additional cleanup and refactoring of the inotify code, including moving the non-TLS-specific filesystem watching code out of the `tls::config` module and into a new `fs_watch` module. In addition, it adds tests for both the polling-based and inotify-based watch implementations, and changes the polling-based watches to hash the files rather than using timestamps from the file's metadata to detect changes. These changes are originally from #1094 and #1091, respectively, but they're included here because @briansmith asked that all the changes be made in one PR. Closes #1094. Closes #1091. Fixes #1090. Fixes #1097. Fixes #1061. Signed-off-by: Eliza Weisman <eliza@buoyant.io> * test: Use proxy instead of lb for external test traffic (#1129) * test: Use proxy instead of lb for external test traffic * Adjust timeouts on install and get tests Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * Display proxy container errors in the Web UI (#1130) * Display proxy container errors in the Web UI Add an error modal to display pod errors Add icon to data tables to indicate errors are present Display errors on the Service Mesh Overview Page and all the resource pages * Start running integration tests in CI (#1064) * Start running integration tests in CI * Add gcp helper funcs * Split integration test cleanup into separate phase Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * Fix conduit version issue in integration tests (#1139) Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * Keep accepting new connections after TLS handshake error. (#1134) When a TLS handshake error occurs, the proxy just stops accepting requests. It seems my expectations of how `Stream` handles errors were wrong. The test for this will be added in a separate PR after the infrastructure needed for TLS testing is added. (This is a chicken and egg problem.) Signed-off-by: Brian Smith <brian@briansmith.org> * Add optional TLS client certificate authentication. (#1135) Refactor the way the TLS trust anchors are configured in preparation for the client and server authenticating each others' certificates. Make the use of client certificates optional pending the implementation of authorization policy. Signed-off-by: Brian Smith <brian@briansmith.org> * Attempt to load TLS settings immediately prior to starting watch (#1137) Previously, the proxy would not attempt to load its TLS certificates until a fs watch detected that one of them had changed. This means that if the proxy was started with valid files already at the configured paths, it would not load them until one of the files changed. This branch fixes that issue by starting the stream of changes with one event _followed_ by any additional changes detected by watching the filesystem. I've manually tested that this fixes the issue, both on Linux and on macOS, and can confirm that this fixes the issue. In addition, when I start writing integration tests for certificate reloading, I'll make sure to include a test to detect any regressions. Closes #1133. Signed-off-by: Eliza Weisman <eliza@buoyant.io> * Proxy: Make the control plane completely optional. (#1132) Proxy: Make the control plane completely optional. * Update Rustls to the latest Git version to fix a bug. (#1143) Using MS Edge and probably other clients with the Conduit proxy when TLS is enabled fails because Rustls doesn't take into consideration that Conduit only supports one signature scheme (ECDSA P-256 SHA-256). This bug was fixed in Rustls when ECDSA support was added, after the latest release. With this change MS Edge can talk to Conduit. Signed-off-by: Brian Smith <brian@briansmith.org> * Enable get for nodes/proxy for Prometheus RBAC (#1142) The `kubernetes-nodes-cadvisor` Prometheus queries node-level data via the Kubernetes API server. In some configurations of Kubernetes, namely minikube and at least one baremetal kubespray cluster, this API call requires the `get` verb on the `nodes/proxy` resource. Enable `get` for `nodes/proxy` for the `conduit-prometheus` service account. Fixes #912 Signed-off-by: Andrew Seigner <siggy@buoyant.io> * Grafana: remove fill and stack from individual resource breakouts (#1092) Remove the filling and stacking in request rate graphs that combine resources, to make it easier to spot outliers. * Grafana: remove fill and stack from individual resource breakouts * Remove all the stacks and fills from request rates everywhere * Build CLI only for host platform (#884) * Build CLI only for host platform Signed-off-by: Alena Varkockova <varkockova.a@gmail.com> * Changes after code review Signed-off-by: Alena Varkockova <varkockova.a@gmail.com> * Fix unbound variable issue in docker-build script (#1146) Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * v0.4.4 release notes (#1145) * v0.4.4 release notes * Tweak wording about adblocker fix Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * Upgrade to webpack 4 and webpack-dev-server 3 (#1138) Speeds up performance of webpack-dev-server. * proxy: Upgrade h2 to 0.1.10 (#1149) This picks up a fix for hyperium/h2#285 * Proxy: Make TLS server aware of its own identity. (#1148) * Proxy: Make TLS server aware of its own identity. When validating the TLS configuration, make sure the certificate is valid for the current pod. Make the pod's identity available at that point in time so it can do so. Since the identity is available now, simplify the validation of our own certificate by using Rustls's API instead of dropping down to the lower-level webpli API. This is a step towards the server differentiating between TLS handshakes it is supposed to terminate vs. TLS handshakes it is supposed to pass through. This is also a step toward the client side (connect) of TLS, which will reuse much of the configuration logic. Signed-off-by: Brian Smith <brian@briansmith.org> * proxy: Add `tls="true"` metric label to connections accepted with TLS (#1050) Depends on #1047. This PR adds a `tls="true"` label to metrics produced by TLS connections and requests/responses on those connections, and a `tls="no_config"` label on connections where TLS was enabled but the proxy has not been able to load a valid TLS configuration. Currently, these labels are only set on accepted connections, as we are not yet opening encrypted connections, but I wired through the `tls_status` field on the `Client` transport context as well, so when we start opening client connections with TLS, the label will be applied to their metrics as well. Closes #1046 Signed-off-by: Eliza Weisman <eliza@buoyanbt.io> * Truncate very long error messages, small tweaks to error messages (#1150) - If error messages are very long, truncate them and display a toggle to show the full message - Tweak the headings - remove Pod, Container and Image - instead show them as titles - Also move over from using Ant's Modal.method to the plain Modal component, which is a little simpler to hook into our other renders. * proxy: Clarify Outbound::recognize (#1144) The comments in Outbound::recognize had become somewhat stale as the logic changed. Furthermore, this implementation may be easier to understand if broken into smaller pieces. This change reorganizes the Outbound:recognize method into helper methods--`destination`, `host_port`, and `normalize`--each with accompanying docstrings that more accurately reflect the current implementation. This also has the side-effect benefit of eliminating a string clone on every request. * Add integration tests for tap (#1152) * Add integration tests for tap * Collect fewer tap events Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * dest service: close open streams on shutdown (#1156) * dest service: close open streams on shutdown * Log instead of print in pkg packages * Convert ServerClose to a receive-only channel Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * Don't panic on stats that aren't included in StatAllResourceTypes (#1154) Problem `conduit stat` would cause a panic for any resource that wasn't in the list of StatAllResourceTypes This bug was introduced by https://github.com/runconduit/conduit/pull/1088/files Solution Fix writeStatsToBuffer to not depend on what resources are in StatAllResourceTypes Also adds a unit test and integration test for `conduit stat ns` * Fix dashboard integration test (#1160) Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * Proxy: Add TLS client infrastructure. (#1158) Move TLS cipher suite configuration to tls::config. Use the same configuration to act as a client and a server. Signed-off-by: Brian Smith <brian@briansmith.org> * Proxy: More carefully keep track of the reason TLS isn't used. (#1164) * Proxy: More carefully keep track of the reason TLS isn't used. There is only one case where we dynamically don't know whether we'll have an identity to construct a TLS connection configuration. Refactor the code with that in mind, better documenting all the reasons why an identity isn't available. Signed-off-by: Brian Smith <brian@briansmith.org> * Don't allow stat requests for named resources in --all-namespaces (#1163) Don't allow the CLI or Web UI to request named resources if --all-namespaces is used. This follows kubectl, which also does not allow requesting named resources over all namespaces. This PR also updates the Web API's behaviour to be in line with the CLI's. Both will now default to the default namespace if no namespace is specified. * Enable optional parallel build of docker images (#978) * Enable optional parallel build of docker images By default, docker does image builds in a single thread. For our containers, this is a little slow on my system. Using `parallel` allows for *optional* improvements in speed there. Before: 41s After: 22s * Move parallel help text to stderr * proxy: re-enabled vectored writes through our dynamic Io trait object. (#1167) This adds `Io::write_buf_erased` that doesn't required `Self: Sized`, so it can be called on trait objects. By using this method, specialized methods of `TcpStream` (and others) can use their `write_buf` to do vectored writes. Since it can be easy to forget to call `Io::write_buf_erased` instead of `Io::write_buf`, the concept of making a `Box<Io>` has been made private. A new type, `BoxedIo`, implements all the super traits of `Io`, while making the `Io` trait private to the `transport` module. Anything hoping to use a `Box<Io>` can use a `BoxedIo` instead, and know that the write buf erase dance is taken care of. Adds a test to `transport::io` checking that the dance we've done does indeed call the underlying specialized `write_buf` method. Closes #1162 * proxy: add HTTP/1.1 Upgrade support automatically (#1126) Any HTTP/1.1 requests seen by the proxy will automatically set up to prepare such that if the proxied responses agree to an upgrade, the two connections will converted into a standard TCP proxy duplex. Implementation ----------------- This adds a new type, `transparency::Http11Upgrade`, which is a sort of rendezvous type for triggering HTTP/1.1 upgrades. In the h1 server service, if a request looks like an upgrade (`h1::wants_upgrade`), the request body is decorated with this new `Http11Upgrade` type. It is actually a pair, and so the second half is put into the request extensions, so that the h1 client service may look for it right before serialization. If it finds the half in the extensions, it decorates the *response* body with that half (if it looks like a response upgrade (`h1::is_upgrade`)). The `HttpBody` type now has a `Drop` impl, which will look to see if its been decorated with an `Http11Upgrade` half. If so, it will check for hyper's new `Body::on_upgrade()` future, and insert that into the half. When both `Http11Upgrade` halves are dropped, its internal `Drop` will look to if both halves have supplied an upgrade. If so, the two `OnUpgrade` futures from hyper are joined on, and when they succeed, a `transparency::tcp::duplex()` future is created. This chain is spawned into the default executor. The `drain::Watch` signal is carried along, to ensure upgraded connections still count towards active connections when the proxy wants to shutdown. Closes #195 * Add controller admin servers and readiness probes (#1168) * Add controller admin servers and readiness probes * Tweak readiness probes to be more sane * Refactor based on review feedback Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * bin: Remove unused script (#1153) Committed in error. Signed-off-by: Eliza Weisman <eliza@buoyant.io> * Proxy: Implement TLS conditional accept more like TLS conditional connect. (#1166) * Proxy: Implement TLS conditional accept more like TLS conditional connect. Clean up the accept side of the TLS configuration logic. Signed-off-by: Brian Smith <brian@briansmith.org> * Upgrade prometheus to v2.3.1 (#1174) Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * proxy: Document tls::config::watch_for_config_changes (#1176) While investigating TLS configuration, I found myself wanting a docstring on `tls::config::watch_for_config_changes`. This has one minor change in functionality: now, `future::empty()` is returned instead of `future:ok(())` so that the task never completes. It seems that, ultimately, we'll want to treat it as an error if we lose the ability to receive configuration updates. * Add CA certificate bundle distributor to conduit install (#675) * Add CA certificate bundle distributor to conduit install * Update ca-distributor to use shared informers * Only install CA distributor when --enable-tls flag is set * Only copy CA bundle into namespaces where inject pods have the same controller * Update API config to only watch pods and configmaps * Address review feedback Signed-off-by: Kevin Lingerfelt <kl@buoyant.io> * Add probes and log termination policy for distributor (#1178) Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

klingerf self-assigned this Apr 4, 2018

klingerf added the review label Apr 4, 2018

klingerf mentioned this pull request Apr 4, 2018

Use HTTPS instead of plaintext HTTP to communicate with the control plane from the proxy #310

Closed

4 tasks

klingerf force-pushed the kl/distributor branch from df9dec3 to 9143deb Compare April 6, 2018 21:32

olix0r added this to the 0.5.0 milestone Apr 7, 2018

klingerf force-pushed the kl/distributor branch 3 times, most recently from c42af59 to a4d1834 Compare April 19, 2018 00:27

wmorgan requested a review from briansmith April 27, 2018 16:23

klingerf force-pushed the kl/distributor branch from a4d1834 to e99be79 Compare May 10, 2018 17:51

klingerf force-pushed the kl/distributor branch from e99be79 to 8ec53f4 Compare May 30, 2018 01:50

klingerf force-pushed the kl/distributor branch 4 times, most recently from 3c3813b to c8003f5 Compare June 13, 2018 19:04

klingerf mentioned this pull request Jun 13, 2018

Allow k8s API clients to watch a subset of resources #1118

Merged

klingerf force-pushed the kl/distributor branch from 8225d77 to 03c550b Compare June 14, 2018 18:29

siggy reviewed Jun 14, 2018

View reviewed changes

klingerf added 6 commits June 14, 2018 15:07

Add CA certificate bundle distributor to conduit install

c00d70a

Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

Update ca-distributor to use shared informers

c57ac90

Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

Only install CA distributor when --enable-tls flag is set

82f0230

Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

Only copy CA bundle into namespaces where inject pods have the same c…

f36e61a

…ontroller Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

Update API config to only watch pods and configmaps

85dc6dc

Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

Address review feedback

7fcd7a2

Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>

klingerf commented Jun 14, 2018

View reviewed changes

klingerf force-pushed the kl/distributor branch from 03c550b to 7fcd7a2 Compare June 14, 2018 22:08

siggy approved these changes Jun 14, 2018

View reviewed changes

rmars approved these changes Jun 15, 2018

View reviewed changes

klingerf merged commit 12f869e into master Jun 21, 2018

klingerf deleted the kl/distributor branch June 21, 2018 20:12

klingerf mentioned this pull request Jun 21, 2018

Add probes and log termination policy for distributor #1178

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add CA certificate bundle distributor to conduit install #675

Add CA certificate bundle distributor to conduit install #675

klingerf commented Apr 4, 2018

oivindoh commented Apr 27, 2018

klingerf commented Jun 6, 2018

siggy Jun 14, 2018

siggy Jun 14, 2018

klingerf Jun 14, 2018

siggy Jun 14, 2018

siggy Jun 14, 2018

siggy Jun 14, 2018

klingerf Jun 14, 2018 •

edited

Loading

siggy Jun 14, 2018

klingerf Jun 14, 2018

siggy Jun 14, 2018

klingerf Jun 14, 2018

klingerf left a comment

klingerf Jun 14, 2018

klingerf Jun 14, 2018

klingerf Jun 14, 2018

klingerf Jun 14, 2018 •

edited

Loading

siggy left a comment

rmars left a comment

Add CA certificate bundle distributor to conduit install #675

Add CA certificate bundle distributor to conduit install #675

Conversation

klingerf commented Apr 4, 2018

oivindoh commented Apr 27, 2018

klingerf commented Jun 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

klingerf Jun 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

klingerf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

klingerf Jun 14, 2018 • edited Loading

Choose a reason for hiding this comment

siggy left a comment

Choose a reason for hiding this comment

rmars left a comment

Choose a reason for hiding this comment

klingerf Jun 14, 2018 •

edited

Loading

klingerf Jun 14, 2018 •

edited

Loading