There was a problem that caused helm install to not reflect the proper list of ignored inbound and outbound ports. Namely if you supply just one port, that would not get reflected.
To reproduce do a:
```
helm install \
--name=linkerd2 \
--set-file global.identityTrustAnchorsPEM=ca.crt \
--set-file identity.issuer.tls.crtPEM=issuer.crt \
--set-file identity.issuer.tls.keyPEM=issuer.key \
--set identity.issuer.crtExpiry=2021-01-14T14:21:43Z \
--set-string global.proxyInit.ignoreInboundPorts="6666" \
linkerd-edge/linkerd2
```
Check your config:
```bash
$ kubectl get configmap -n linkerd -oyaml | grep ignoreInboundPort
"ignoreInboundPorts":[],
```
Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
## edge-20.1.3
* CLI
* Introduced `linkerd check --pre --linkerd-cni-enabled`, used when the CNI
plugin is used, to check it has been properly installed before proceeding
with the control plane installation
* Added support for the `--as-group` flag so that users can impersonate
groups for Kubernetes operations (thanks @mayankshah160!)
* Controller
* Fixed an issue where an override of the Docker registry was not being
applied to debug containers (thanks @javaducky!)
* Added check for the Subject Alternate Name attributes to the API server
when access restrictions have been enabled (thanks @javaducky!)
* Added support for arbitrary pod labels so that users can leverage the
Linkerd provided Prometheus instance to scrape for their own labels
(thanks @daxmc99!)
* Fixed an issue with CNI config parsing
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
This allows for users of Linkerd to leverage the Prometheus instance
deployed by the mesh for their metric needs. With support for pod labels
outside of the Linkerd metrics users are able to scrape metrics
based upon their own labels.
Signed-off-by: Dax McDonald <dax@rancher.com>
**Subject**
Fixes bug where override of Docker registry was not being applied to debug containers (#3851)
**Problem**
Overrides for Docker registry are not being applied to debug containers and provide no means to correct the image.
**Solution**
This update expands the `data.proxy` configuration section within the Linkerd `ConfigMap` to maintain the overridden image name for debug containers at _install_-time similar to handling of the `proxy` and `proxyInit` images.
This change also enables the further override option of the registry for debug containers at _inject_-time given utilization of the `--registry` CLI option.
**Validation**
Several new unit tests have been created to confirm functionality. In addition, the following workflows were run through:
### Standard Workflow with Custom Registry
This workflow installs Linkerd control plane based upon a custom registry, then injecting the debug sidecar into a service.
* Start with a k8s instance having no Linkerd installation
* Build all images locally using `bin/docker-build`
* Create custom tags (using same version) for generated images, e.g. `docker tag gcr.io/linkerd-io/debug:git-a4ebecb6 javaducky.com/linkerd-io/debug:git-a4ebecb6`
* Install Linkerd with registry override `bin/linkerd install --registry=javaducky.com/linkerd-io | kubectl apply -f -`
* Once Linkerd has been fully initialized, you should be able to confirm that the `linkerd-config` ConfigMap now contains the debug image name, pull policy, and version within the `data.proxy` section
* Request injection of the debug image into an available container. I used the Emojivoto voting service as described in https://linkerd.io/2/tasks/using-the-debug-container/ as `kubectl -n emojivoto get deploy/voting -o yaml | bin/linkerd inject --enable-debug-sidecar - | kubectl apply -f -`
* Once the deployment creates a new pod for the service, inspection should show that the container now includes the "linkerd-debug" container name based on the applicable override image seen previously within the ConfigMap
* Debugging can also be verified by viewing debug container logs as `kubectl -n emojivoto logs deploy/voting linkerd-debug -f`
* Modifying the `config.linkerd.io/enable-debug-sidecar` annotation, setting to “false”, should show that the pod will be recreated no longer running the debug container.
### Overriding the Custom Registry Override at Injection
This builds upon the “Standard Workflow with Custom Registry” by overriding the Docker registry utilized for the debug container at the time of injection.
* “Clean” the Emojivoto voting service by removing any Linkerd annotations from the deployment
* Request injection similar to before, except provide the `--registry` option as in `kubectl -n emojivoto get deploy/voting -o yaml | bin/linkerd inject --enable-debug-sidecar --registry=gcr.io/linkerd-io - | kubectl apply -f -`
* Inspection of the deployment config should now show the override annotation for `config.linkerd.io/debug-image` having the debug container from the new registry. Viewing the running pod should show that the `linkerd-debug` container was injected and running the correct image. Of note, the proxy and proxy-init images are still running the “original” override images.
* As before, modifying the `config.linkerd.io/enable-debug-sidecar` annotation setting to “false”, should show that the pod will be recreated no longer running the debug container.
### Standard Workflow with Default Registry
This workflow is the typical workflow which utilizes the standard Linkerd image registry.
* Uninstall the Linkerd control plane using `bin/linkerd install --ignore-cluster | kubectl delete -f -` as described at https://linkerd.io/2/tasks/uninstall/
* Clean the Emojivoto environment using `curl -sL https://run.linkerd.io/emojivoto.yml | kubectl delete -f -` then reinstall using `curl -sL https://run.linkerd.io/emojivoto.yml | kubectl apply -f -`
* Perform standard Linkerd installation as `bin/linkerd install | kubectl apply -f -`
* Once Linkerd has been fully initialized, you should be able to confirm that the `linkerd-config` ConfigMap references the default debug image of `gcr.io/linkerd-io/debug` within the `data.proxy` section
* Request injection of the debug image into an available container as `kubectl -n emojivoto get deploy/voting -o yaml | bin/linkerd inject --enable-debug-sidecar - | kubectl apply -f -`
* Debugging can also be verified by viewing debug container logs as `kubectl -n emojivoto logs deploy/voting linkerd-debug -f`
* Modifying the `config.linkerd.io/enable-debug-sidecar` annotation, setting to “false”, should show that the pod will be recreated no longer running the debug container.
### Overriding the Default Registry at Injection
This workflow builds upon the “Standard Workflow with Default Registry” by overriding the Docker registry utilized for the debug container at the time of injection.
* “Clean” the Emojivoto voting service by removing any Linkerd annotations from the deployment
* Request injection similar to before, except provide the `--registry` option as in `kubectl -n emojivoto get deploy/voting -o yaml | bin/linkerd inject --enable-debug-sidecar --registry=javaducky.com/linkerd-io - | kubectl apply -f -`
* Inspection of the deployment config should now show the override annotation for `config.linkerd.io/debug-image` having the debug container from the new registry. Viewing the running pod should show that the `linkerd-debug` container was injected and running the correct image. Of note, the proxy and proxy-init images are still running the “original” override images.
* As before, modifying the `config.linkerd.io/enable-debug-sidecar` annotation setting to “false”, should show that the pod will be recreated no longer running the debug container.
Fixes issue #3851
Signed-off-by: Paul Balogh javaducky@gmail.com
As part of the effort to remove the "experimental" label from the CNI plugin, this PR introduces cni checks to `linkerd check`
Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
## edge-20.1.2
* CLI
* Added HA specific checks to `linkerd check` to ensure that the `kube-system`
namespace has the `config.linkerd.io/admission-webhooks:disabled`
label set
* Fixed a problem causing the presence of unnecessary empty fields in
generated resource definitions (thanks @mayankshah1607)
* Proxy
* Fixed an issue that could cause the OpenCensus exporter to stall
* Internal
* Added validation to incoming sidecar injection requests that ensures
the value of `linkerd.io/inject` is either `enabled` or `disabled`
(thanks @mayankshah1607)
Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
* sort alphabatically and update prometheus version
* update version field to static
* sort linkerd2-cni readme
* switch to uppercase CNI
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
There are a few dangling references to old release versions in our charts and readmes.
I've removed as many of these references as possible so that we no longer need to worry about them getting out of date. The one reference that remains is `cniPluginVersion` and this will need to be manually updated as part of the release process.
Signed-off-by: Alex Leong <alex@buoyant.io>
## edge-20.1.1
This edge release includes experimental improvements to the Linkerd proxy's
request buffering and backpressure infrastructure.
Additionally, we've fixed several bugs when installing Linkerd with Helm,
updated the CLI to allow using both port numbers _and_ port ranges with the
`--skip-inbound-ports` and `--skip-outbound-ports` flags, and fixed a dashboard
error that can occur if the dashboard is open in a browser while updating Linkerd.
**Note**: The `linkerd-proxy` version included with this release is more
experimental than usual. We'd love your help testing, but be aware that there
might be stability issues.
* CLI
* Added the ability to pass both port numbers and port ranges to
`--skip-inbound-ports` and `--skip-outbound-ports` (thanks to @javaducky!)
* Controller
* Fixed a race condition in the `linkerd-web` service
* Updated Prometheus to 2.15.2 (thanks @Pothulapati)
* Web UI
* Fixed an error when refreshing an already open dashboard when the Linkerd
version has changed
* Proxy
* Internal changes to the proxy's request buffering and backpressure
infrastructure
* Helm
* Fixed the `linkerd-cni` Helm chart not setting proper namespace annotations
and labels
* Fixed certificate issuance lifetime not being set when installing through
Helm
* More improvements to Helm best practices (thanks to @Pothulapati!)
`cniEnabled` was hard-coded to `false` in the `_config.tpl` template, thus always adding the init container during injection regardless of having installed the control plane with `--set noInitContainer=true`.
This affects injection after having installed with Helm, not when having installed with the CLI.
Repro steps under the edge-19.12.3's tag:
```bash
$ helm install charts/linkerd2-cni
# wait for the linkerd-cni-xxx pod to come up
# refresh linkerd2's chart dependencies
$ bin/helm-build
# overrides.yaml should contain all the mandatory values for certs
$ helm install -f overrides.yaml --set noInitContainer=true --set installNamespace=false charts/linkerd2
# verify the global config `cniEnabled` is NOT being persisted appropriately
$ k -n linkerd get cm linkerd-config -oyaml | grep cni
"cniEnabled": false,
# install and inject emojivoto
$ curl https://run.linkerd.io/emojivoto.yml|bin/go-run cli inject -|k apply -f -
# verify that the init container is being (unexpectedly) added
$ k -n emojivoto get po emoji-xxxxx-xxx -oyaml | grep initContainer
initContainers:
initContainerStatuses:
```
In this branch:
```bash
$ helm install charts/linkerd2-cni
# wait for the linkerd-cni-xxx pod to come up
# refresh linkerd2's chart dependencies
$ bin/helm-build
# overrides.yaml should contain all the mandatory values for certs
$ helm install -f overrides.yaml --set noInitContainer=true --set installNamespace=false charts/linkerd2
# verify the global config `cniEnabled` is being persisted appropriately
$ k -n linkerd get cm linkerd-config -oyaml | grep cni
"cniEnabled": true,
# install and inject emojivoto
$ curl https://run.linkerd.io/emojivoto.yml|bin/go-run cli inject -|k apply -f -
# verify that the init container is NOT being added
$ k -n emojivoto get po emoji-xxxxx-xxx -oyaml | grep initContainer
# nothing returned
```
This replaces #3872
Due to wrong snake casing, lifetime setting lifetime issuance was not reflected when installing through helm. This commit solved that problem
Signed-off-by: Zahari Dichev zaharidichev@gmail.com
* The `linkerd-cni` chart should set proper annotations/labels for the namespace
When installing through Helm, the `linkerd-cni` chart will (by default)
install itself under the same namespace ("linkerd") that the `linkerd` chart will be
installed aftewards. So it needs to set up the proper annotations and labels.
* Fix Helm install when disabling init containers
To install linkerd using Helm after having installed linkerd's CNI plugin, one needs to `--set noInitContainer=true`.
But to determine whether to use init containers or not, we weren't
evaluating that, but instead `Values.proxyInit`, which is indeed null
when installing through the CLI but not when installing with Helm. So
init containers were being set despite having passed `--set
noInitContainers=true`.
* update flags to smaller
* add tests for the same
* fix control plane trace flag
* add tests for controlplane tracing install
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
* Changes for edge-19.12.3
Signed-off-by: Charles Pretzer <charles@buoyant.io>
* CHANGES.md updates based on feedback
Signed-off-by: Charles Pretzer <charles@buoyant.io>
* Fix flag name
Signed-off-by: Charles Pretzer <charles@buoyant.io>
Fixes#3444Fixes#3443
## Background and Behavior
This change adds support for the destination service to resolve Get requests which contain a service clusterIP or pod ip as the `Path` parameter. It returns the stream of endpoints, just as if `Get` had been called with the service's authority. This lays the groundwork for allowing the proxy to TLS TCP connections by allowing the proxy to do destination lookups for the SO_ORIG_DST of tcp connections. When that ip address corresponds to a service cluster ip or pod ip, the destination service will return the endpoints stream, including the pod metadata required to establish identity.
Prior to this change, attempting to look up an ip address in the destination service would result in a `InvalidArgument` error.
Updating the `GetProfile` method to support ip address lookups is out of scope and attempts to look up an ip address with the `GetProfile` method will result in `InvalidArgument`.
## Implementation
We do this by creating a `IPWatcher` which wraps the `EndpointsWatcher` and supports lookups by ip. `IPWatcher` maintains a mapping up clusterIPs to service ids and translates subscriptions to an IP address into a subscription to the service id using the underlying `EndpointsWatcher`.
Since the service name is no longer always infer-able directly from the input parameters, we restructure `EndpointTranslator` and `PodSet` so that we propagate the service name from the endpoints API response.
## Testing
This can be tested by running the destination service locally, using the current kube context to connect to a Kubernetes cluster:
```
go run controller/cmd/main.go destination -kubeconfig ~/.kube/config
```
Then lookups can be issued using the destination client:
```
go run controller/script/destination-client/main.go -path 192.168.54.78:80 -method get -addr localhost:8086
```
Service cluster ips and pod ips can be used as the `path` argument.
Signed-off-by: Alex Leong <alex@buoyant.io>
The Kubernetes docs recommend a common set of labels for resources:
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels
Add the following 3 labels to all control-plane workloads:
```
app.kubernetes.io/name: controller # or destination, etc
app.kubernetes.io/part-of: Linkerd
app.kubernetes.io/version: edge-X.Y.Z
```
Fixes#3816
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
* Inject preStop hook into the proxy sidecar container to stop it last
This commit adds support for a Graceful Shutdown technique that is used
by some Kubernetes administrators while the more perspective
configuration is being discussed in
https://github.com/kubernetes/kubernetes/issues/65502
The problem is that RollingUpdate strategy does not guarantee that all
traffic will be sent to a new pod _before_ the previous pod is removed.
Kubernetes inside is an event-driven system and when a pod is being
terminating, several processes can receive the event simultaneously.
And if an Ingress Controller gets the event too late or processes it
slower than Kubernetes removes the pod from its Service, users requests
will continue flowing into the black whole.
According [to the documentation](https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods)
> 1. If one of the Pod’s containers has defined a `preStop` hook,
> it is invoked inside of the container. If the `preStop` hook is still
> running after the grace period expires, step 2 is then invoked with
> a small (2 second) extended grace period.
>
> 2. The container is sent the `TERM` signal. Note that not all
> containers in the Pod will receive the `TERM` signal at the same time
> and may each require a preStop hook if the order in which
> they shut down matters.
This commit adds support for the `preStop` hook that can be configured
in three forms:
1. As command line argument `--wait-before-exit-seconds` for
`linkerd inject` command.
2. As `linkerd2` Helm chart value `Proxy.WaitBeforeExitSeconds`.
2. As `config.alpha.linkerd.io/wait-before-exit-seconds` annotation.
If configured, it will add the following preHook to the proxy container
definition:
```yaml
lifecycle:
preStop:
exec:
command:
- /bin/bash
- -c
- sleep {{.Values.Proxy.WaitBeforeExitSeconds}}
```
To achieve max benefit from the option, the main container should have
its own `preStop` hook with the `sleep` command inside which has
a smaller period than is set for the proxy sidecar. And none of them
must be bigger than `terminationGracePeriodSeconds` configured for the
entire pod.
An example of a rendered Kubernetes resource where
`.Values.Proxy.WaitBeforeExitSeconds` is equal to `40`:
```yaml
# application container
lifecycle:
preStop:
exec:
command:
- /bin/bash
- -c
- sleep 20
# linkerd-proxy container
lifecycle:
preStop:
exec:
command:
- /bin/bash
- -c
- sleep 40
terminationGracePeriodSeconds: 160 # for entire pod
```
Fixes#3747
Signed-off-by: Eugene Glotov <kivagant@gmail.com>
This PR adds support for CronJobs and ReplicaSets to `linkerd inject`, the web
dashboard and CLI. It adds a new Grafana dashboard for each kind of resource.
Closes#3614Closes#3630Closes#3584Closes#3585
Signed-off-by: Sergio Castaño Arteaga tegioz@icloud.com
Signed-off-by: Cintia Sanchez Garcia cynthiasg@icloud.com
* Pods with non empty securitycontext capabilities fail to be injected
Followup to #3744
The `_capabilities.tpl` template got its variables scope changed in
`Values.Proxy`, which caused inject to fail when security context
capabilities were detected.
Discovered when testing injecting the nginx ingress controller.
## edge-19.12.1
* CLI
* Added condition to the `linkerd stat` command that requires a window size
of at least 15 seconds to work properly with Prometheus
* Web UI
* Fixed a table wrap issue in the resource detail view that made sidebar
font size inconsistent
* Internal
* Fixed whitespace path handling in non-docker build scripts (thanks
@joakimr-axis!)
* Removed calico logutils dependency that was incompatible with go 1.13
* Updated Helm templates to use fully-qualified variable references based
upon Helm best practices (thanks @javaducky!)
* Added new browser tests for URL routing in dashboard
Signed-off-by: Kevin Leimkuhler <kleimkuhler@icloud.com>
Chart.yaml includes an appVersion field which is overwritten by CI when a helm tarball is published. Therefore, the value of this field is irrelevant. It can be confusing that it appears that the field contains a valid, out-of-date edge version.
This change makes it more obvious that the field should not be considered to be a valid and current edge version.
Signed-off-by: Alex Leong <alex@buoyant.io>
## edge-19.11.3
* CLI
* Added a check that ensures using `--namespace` and `--all-namespaces`
results in an error as they are mutually exclusive
* Internal
* Fixed an issue causing `tap`, `injector` and `sp-validator` to use
old certificates after `helm upgrade` due to not being restarted
* Fixed incomplete Swagger definition of the tap api, causing benign
error logging in the kube-apiserver
Signed-off-by: zaharidichev <zaharidichev@gmail.com>
## edge-19.11.2
* CLI
* Added a `Dashboard.Replicas` parameter to the Linkerd Helm chart to allow
configuring the number of dashboard replicas (thanks @KIVagant!)
* Removed redundant service profile check (thanks @alenkacz!)
* Web UI
* Added `linkerd check` to the dashboard in the `/controlplane` view
* Added request and response headers to the `tap` expanded view in the
dashboard
* Internal
* Removed the destination container from the linkerd-controller deployment as
it now runs in the linkerd-destination deployment
* Upgraded Go to version 1.13.4
Signed-off-by: Alex Leong <alex@buoyant.io>
* Replaced `uuid` with `uid` from linkerd-config resource
Fixes#3621
Removed the old `uuid` for identifying linkerd installations, and
replaced it with the `uid` property from the `linkerd-config` ConfigMap.
I tested that this `uid` remains the same by updating the config and
also upgrading linkerd, using both the CLI and Helm.
Note that this required granting `linkerd-web` RBAC access to the
`linkerd-config` Config.
I also added an integration test to verify the stability of the uid.
`linkerd check` can now be run from the dashboard in the `/controlplane` view.
Once the check results are received, they are displayed in a modal in a similar
style to the CLI output.
Closes#3613
## edge-19.10.5
This edge release adds support for integrating Linkerd's public-key
infrastructure with an external certificate issuer such as [`cert-manager`],
adds distributed tracing support to the Linkerd control plane, and adds
protection against DNS rebinding attacks to the web dashboard. In addition, it
includes several improvements to the Linkerd CLI.
* CLI
* Added a new `--identity-external-issuer` flag to `linkerd install` that
configures Linkerd to use certificates issued by an external certificate
issuer (such as `cert-manager`)
* Added support for injecting a namespace to `linkerd inject` (thanks
@mayankshah1607!)
* Added checks to `linkerd check --preinstall` ensuring Kubernetes Secrets
can be created and accessed
* Fixed `linkerd tap` sometimes displaying incorrect pod names for unmeshed
IPs that match multiple running pods
* Controller
* Added support for using trust anchors from an external certificate issuer
(such as `cert-mananger`) to the `linkerd-identity` service
* Web UI
* Added `Host:` header validation to the `linkerd-web` service, to protect
against DNS rebinding attacks
* Internal
* Added new `--trace-collector` and `--trace-collector-svc-account` flags to
`linkerd inject` that configures the OpenCensus trace collector used by
proxies in the injected workload (thanks @Pothulapati!)
* Added a new `--control-plane-tracing` flag to `linkerd install` that enables
distributed tracing in the control plane (thanks @Pothulapati!)
* Added distributed tracing support to the control plane (thanks
@Pothulapati!)
Also, thanks to @joakimr-axis for several fixes and improvements to internal
build scripts!
* DNS rebinding protection for the dashboard
Fixes#3083 and replacement for #3629
This adds a new parameter to the `linkerd-web` container `enforcedHost`
that establishes the regexp that the Host header must enforce, otherwise
it returns an error.
This parameter will be hard-coded for now, in `linkerd-web`'s deployment
yaml.
Note this also protects the dashboard because that's proxied from
`linkerd-web`.
Also note this means the usage of `linkerd dashboard --address` will
require the user to change that parameter in the deployment yaml (or
have Kustomize do it).
How to test:
- Run `linkerd dashboard`
- Go to http://rebind.it:8080/manager.html and change the target port to
50750
- Click on “Start Attack” and wait for a minute.
- The response from the dashboard will be returned, showing an 'Invalid
Host header' message returned by the dashboard. If the attack would have
succeeded then the dashboard's html would be shown instead.
Signed-off-by: Alejandro Pedraza <alejandro@buoyant.io>
* If tap source IP matches many running pods then only show the IP
When an unmeshed source ip matched more than one running pod, tap was
showing the names for all those pods, even though the didn't necessary
originate the connection. This could be reproduced when using pod
network add-on such as Calico.
With this change, if a node matches, return it, otherwise we proceed to look for a matching pod. If exactly one running pod matches we return it. Otherwise we return just the IP.
Fixes#3103
* Add support for --identity-issuer-mode flag to install cmd
* Change flag to be a bool
* Read correct data form identity when external issuer is used
* Add ability for identity service to dynamically reload certs
* Fix failing tests
* Minor refactor
* Load trust anchors from identity issuer secret
* Make identity service actually watch for issuer certs updates
* Add some testing around cmd line identity options validation
* Add tests ensuring that identity service loads issuer
* Take into account external-issuer flag during upgrade + tests
* Fix failing upgrade test
* Address initial review feedback
* Address further review feedback on cli and helm
* Do not persist --identity-external-issuer
* Some improvements to identitiy service
* Bring back persistane of external issuer flag
* Address more feedback
* Update dockerfiles shas
* Publishing k8s events on issuer certs rotation
* Ensure --ignore-cluster+external issuer is not supported
* Update go-deps shas
* Transition to identity issuer scheme based configuration
* Use k8s consts for secret file names
Signed-off-by: zaharidichev <zaharidichev@gmail.com>