mirror of https://github.com/linkerd/linkerd2.git
5 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tarun Pothulapati
|
92421d047a
|
core: use serviceAccountToken volume for pod authentication (#7117)
Fixes #3260 ## Summary Currently, Linkerd uses a service Account token to validate a pod during the `Certify` request with identity, through which identity is established on the proxy. This works well and good, as Kubernetes attaches the `default` service account token of a namespace as a volume (unless overridden with a specific service account by the user). Catch here being that this token is aimed at the application to talk to the kubernetes API and not specifically for Linkerd. This means that there are [controls outside of Linkerd](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server), to manage this service token, which users might want to use, [causing problems with Linkerd](https://github.com/linkerd/linkerd2/issues/3183) as Linkerd might expect it to be present. To have a more granular control over the token, and not rely on the service token that can be managed externally, [Bound Service Tokens](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens) can be used to generate tokens that are specifically for Linkerd, that are bound to a specific pod, along with an expiry. ## Background on Bounded Service Tokens This feature has been GA’ed in Kubernetes 1.20, and is enabled by default in most cloud provider distributions. Using this feature, Kubernetes can be asked to issue specific tokens for linkerd usage (through audience bound configuration), with a specific expiry time (as the validation happens every 24 hours when establishing identity, we can follow the same), bounded to a specific pod (meaning verification fails if the pod object isn’t available). Because of all these bounds, and not being able to use this token for anything else, This feels like the right thing to rely on to validate a pod to issue a certificate. ### Pod Identity Name We still use the same service account name as the pod identity (used with metrics, etc) as these tokens are all generated from the same base service account attached to the pod (could be defualt, or the user overriden one). This can be verified by looking at the `user` field in the `TokenReview` response. <details> <summary>Sample TokenReview response</summary> Here, The new token was created for the vault audience for a pod which had a serviceAccount token volume projection and was using the `mine` serviceAccount in the default namespace. ```json "kind": "TokenReview", "apiVersion": "authentication.k8s.io/v1", "metadata": { "creationTimestamp": null, "managedFields": [ { "manager": "curl", "operation": "Update", "apiVersion": "authentication.k8s.io/v1", "time": "2021-10-19T19:21:40Z", "fieldsType": "FieldsV1", "fieldsV1": {"f:spec":{"f:audiences":{},"f:token":{}}} } ] }, "spec": { "token": "....", "audiences": [ "vault" ] }, "status": { "authenticated": true, "user": { "username": "system:serviceaccount:default:mine", "uid": "889a81bd-e31c-4423-b542-98ddca89bfd9", "groups": [ "system:serviceaccounts", "system:serviceaccounts:default", "system:authenticated" ], "extra": { "authentication.kubernetes.io/pod-name": [ "nginx" ], "authentication.kubernetes.io/pod-uid": [ "ebf36f80-40ee-48ee-a75b-96dcc21466a6" ] } }, "audiences": [ "vault" ] } ``` </details> ## Changes - Update `proxy-injector` and install scripts to include the new projected Volume and VolumeMount. - Update the `identity` pod to validate the token with the linkerd audience key. - Added `identity.serviceAccountTokenProjection` to disable this feature. - Updated err'ing logic with `autoMountServiceAccount: false` to fail only when this feature is disabled. Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com> |
|
Alejandro Pedraza
|
4c634a3816
|
Have webhooks refresh their certs automatically (#5282)
* Have webhooks refresh their certs automatically Fixes partially #5272 In 2.9 we introduced the ability for providing the certs for `proxy-injector` and `sp-validator` through some external means like cert-manager, through the new helm setting `externalSecret`. We forgot however to have those services watch changes in their secrets, so whenever they were rotated they would fail with a cert error, with the only workaround being to restart those pods to pick the new secrets. This addresses that by first abstracting out `FsCredsWatcher` from the identity controller, which now lives under `pkg/tls`. The webhook's logic in `launcher.go` no longer reads the certs before starting the https server, moving that instead into `server.go` which in a similar way as identity will receive events from `FsCredsWatcher` and update `Server.cert`. We're leveraging `http.Server.TLSConfig.GetCertificate` which allows us to provide a function that will return the current cert for every incoming request. ### How to test ```bash # Create some root cert $ step certificate create linkerd-proxy-injector.linkerd.svc ca.crt ca.key \ --profile root-ca --no-password --insecure --san linkerd-proxy-injector.linkerd.svc # configure injector's caBundle to be that root cert $ cat > linkerd-overrides.yaml << EOF proxyInjector: externalSecret: true caBundle: | < ca.crt contents> EOF # Install linkerd. The injector won't start untill we create the secret below $ bin/linkerd install --controller-log-level debug --config linkerd-overrides.yaml | k apply -f - # Generate an intermediatery cert with short lifespan step certificate create linkerd-proxy-injector.linkerd.svc ca-int.crt ca-int.key --ca ca.crt --ca-key ca.key --profile intermediate-ca --not-after 4m --no-password --insecure --san linkerd-proxy-injector.linkerd.svc # Create the secret using that intermediate cert $ kubectl create secret tls \ linkerd-proxy-injector-k8s-tls \ --cert=ca-int.crt \ --key=ca-int.key \ --namespace=linkerd # start following the injector log $ k -n linkerd logs -f -l linkerd.io/control-plane-component=proxy-injector -c proxy-injector # Inject emojivoto. The pods should be injected normally $ bin/linkerd inject https://run.linkerd.io/emojivoto.yml | kubectl apply -f - # Wait about 5 minutes and delete a pod $ k -n emojivoto delete po -l app=emoji-svc # You'll see it won't be injected, and something like "remote error: tls: bad certificate" will appear in the injector logs. # Regenerate the intermediate cert $ step certificate create linkerd-proxy-injector.linkerd.svc ca-int.crt ca-int.key --ca ca.crt --ca-key ca.key --profile intermediate-ca --not-after 4m --no-password --insecure --san linkerd-proxy-injector.linkerd.svc # Delete the secret and recreate it $ k -n linkerd delete secret linkerd-proxy-injector-k8s-tls $ kubectl create secret tls \ linkerd-proxy-injector-k8s-tls \ --cert=ca-int.crt \ --key=ca-int.key \ --namespace=linkerd # Wait a couple of minutes and you'll see some filesystem events in the injector log along with a "Certificate has been updated" entry # Then delete the pod again and you'll see it gets injected this time $ k -n emojivoto delete po -l app=emoji-svc ``` |
|
|
Tarun Pothulapati
|
d0caaa86c4
|
Bump k8s client-go to v0.19.2 (#5002)
Fixes #4191 #4993 This bumps Kubernetes client-go to the latest v0.19.2 (We had to switch directly to 1.19 because of this issue). Bumping to v0.19.2 required upgrading to smi-sdk-go v0.4.1. This also depends on linkerd/stern#5 This consists of the following changes: - Fix ./bin/update-codegen.sh by adding the template path to the gen commands, as it is needed after we moved to GOMOD. - Bump all k8s related dependencies to v0.19.2 - Generate CRD types, client code using the latest k8s.io/code-generator - Use context.Context as the first argument, in all code paths that touch the k8s client-go interface Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com> |
|
Zahari Dichev
|
0017f9a60a |
Cert manager support (#3600)
* 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> |
|
Oliver Gould
|
790c13b3b2
|
Introduce the Identity controller implementation (#2521)
This change introduces a new Identity service implementation for the `io.linkerd.proxy.identity.Identity` gRPC service. The `pkg/identity` contains a core, abstract implementation of the service (generic over both the CA and (Kubernetes) Validator interfaces). `controller/identity` includes a concrete implementation that uses the Kubernetes TokenReview API to validate serviceaccount tokens when issuing certificates. This change does **NOT** alter installation or runtime to include the identity service. This will be included in a follow-up. |