This repository has been archived by the owner on Jun 29, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 49
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Closes: #913 Signed-off-by: knrt10 <kautilya@kinvolk.io>
- Loading branch information
Showing
1 changed file
with
44 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,44 @@ | ||
# Admission-webhook | ||
|
||
Lokomotive has an admission-webhook which runs in it's own namespace `lokomotive`. This document explains how the webhook works adding more security to your cluster. | ||
|
||
## Additional Security | ||
|
||
An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. There are two special controllers: `MutatingAdmissionWebhook` and `ValidatingAdmissionWebhook`. | ||
|
||
When you create a pod, if you do not specify a service account, it is automatically assigned the `default` service account in the same namespace. If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/<podname> -o yaml`), you can see the `spec.serviceAccountName` field has been automatically set. For more information see [kubernetes docs](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/). | ||
|
||
Not every pod needs the ability to utilize the API from within itself. For example, if there is a web application for voting that just counts votes and sends this information to an external data base, there is no need for the app to contact the API server, and therefore a mounted token is unnecessary. An attacker that finds a privileged token on a pod can compromise the cluster, so we need to reduce the attack surface as much as possible | ||
|
||
To avoid manually disabling automounting of default service account, we have a webhook server that patches your service account whenever you either apply any [lokomotive component](./components.md) or create a new namespace. To see how it works follow below steps from your command line. | ||
|
||
```bash | ||
# create a namespace | ||
$ kubectl create ns foo | ||
|
||
# get default service for foo namespace | ||
$ kubectl get sa default -o yaml -n foo | ||
``` | ||
|
||
After following the above steps you can see that `automountServiceAccountToken` is set to false. | ||
|
||
## What does not work | ||
|
||
Currently, on applying cluster `default` service account for `default` namespace is not patched. If you want it patched too, delete the default service account after your cluster is created. | ||
|
||
`$ kubectl delete sa default -n default` | ||
|
||
## How to enable mounting default service account for pods | ||
|
||
You can also opt in of automounting API credentials for a particular pod by setting `automountServiceAccountToken: true`. The pod spec takes precedence over the service account if both specify a `automountServiceAccountToken` value | ||
|
||
```yaml | ||
apiVersion: v1 | ||
kind: Pod | ||
metadata: | ||
name: my-pod | ||
spec: | ||
serviceAccountName: build-robot | ||
automountServiceAccountToken: true | ||
... | ||
``` |