kops/docs/security.md

44 lines
2.3 KiB
Markdown

## Security Notes for Kubernetes
## SSH Access
SSH is allowed to the masters and the nodes, by default from anywhere. However, no public key will be
installed. You can use instead use [ec2 instance connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html),
which is installed in the default AMIs.
If you want to use a fixed key for the cluster, you have to specify `--ssh-public-key <public key file>` on the `kops create cluster` command
or use `kops create sshpublickey`. You can also set the following in the cluster spec:
```yaml
spec:
sshKeyName: <ssh key pair>
```
An EC2 key pair with the name`<ssh key pair>` has to already exist.
By default, SSH is allowed from any address. You can restrict from where SSH connections can be made by
setting either `spec.sshAccess` in the cluster spec or using `kops create cluster --ssh-access`.
To change the SSH public key on an existing cluster:
* `kops delete sshpublickey --name <clustername> sshpublickey`
* `kops create sshpublickey --name <clustername> -i ~/.ssh/newkey.pub`
* `kops update cluster <clustername> --yes` to reconfigure the launch templates.
* `kops rolling-update cluster --name <clustername> --yes` to roll all the machines so they have the new key.
## Docker Configuration
If you are using a private registry such as quay.io, you may be familiar with the inconvenience of managing the `imagePullSecrets` for each namespace. It can also be a pain to use [kOps Hooks](cluster_spec.md#hooks) with private images. To configure docker on all nodes with access to one or more private registries:
* `kops create secret --name <clustername> dockerconfig -f ~/.docker/config.json`
* `kops rolling-update cluster --name <clustername> --yes` to immediately roll all the machines so they have the new key (optional)
This stores the [config.json](https://docs.docker.com/engine/reference/commandline/login/) in `/root/.docker/config.json` on all nodes (include masters) so that both Kubernetes and system containers may use registries defined in it.
Note that this will also work when using containerd.
## Instance IAM roles
All Pods running on your cluster have access to underlying instance IAM role.
Currently, permission scope is quite broad. See [iam_roles.md](iam_roles.md) for details and ways to mitigate that.