docs: add copy button

Author: grampelberg

docs/pages/architecture/access-control.mdx

@@ -55,7 +55,7 @@ There are two ways for an incoming SSH session to get a user identity:
 To validate that a user has access, you can use the `kty users check` command.
 This is a great way to debug why users are not being allowed to connect.
 
-```bash
+```bash copy
 kty users check foo@bar.com
 ```
 
@@ -66,7 +66,7 @@ bindings added to the cluster. The `kty users grant` command is one way to go
 about this, but it is purposely naive. To do something more flexible, you can
 check out `kubectl`:
 
-```bash
+```bash copy
 kubectl create clusterrolebinding foo-bar-com --clusterrole=<my-role> --user=foo@bar.com
 ```
 

docs/pages/getting-started.mdx

@@ -25,7 +25,7 @@ As part of this getting started guide, you will:
 Binares are available on the [releases page][cli-download]. If you have
 homebrew, you can install with:
 
-```bash
+```bash copy
 brew install grampelberg/kty/kty
 ```
 
@@ -47,7 +47,7 @@ In this example, we're using `cluster-admin` because it is everywhere and an
 easy way to get started. You can change this to another role, anything with the
 [minimum permissions](/architecture/access-control#authorization) in fact. Run:
 
-```bash
+```bash copy
 kty users grant cluster-admin me@example.com
 ```
 
@@ -59,14 +59,14 @@ kty users grant cluster-admin me@example.com
 You can verify that this worked and you have the minimum permissions required by
 running:
 
-```bash
+```bash copy
 kty users check me@example.com
 ```
 
 This command runs a `SelfSubjectAccessReview` against your cluster. If you want
 to use `kubectl` instead, you can run:
 
-```bash
+```bash copy
 kubectl auth can-i list pods --as me@example.com
 ```
 
@@ -76,7 +76,7 @@ While it isn't required that you run `kty` on your cluster, it takes care of the
 dependencies. To install the server and associated configuration such as
 `ClusterRole` and `Service` resources, run:
 
-```bash
+```bash copy
 kubectl create ns kty && \
   kty resources install -n kty
 ```
@@ -94,15 +94,15 @@ To clean these resources up, you can run `kty resources delete -n kty`.
 Verify that this is up and running successfully by checking that the pod has
 started up:
 
-```bash
+```bash copy
 kubectl -n kty rollout status deploy server
 ```
 
 Once the pod has started up, you'll want to make sure there's an IP address that
 can be reached. This will also add `cluster.kty.dev` to your `/etc/hosts` file
 so that it is easy to get to the server in the future.
 
-```bash
+```bash copy
 kubectl -n kty get service server --output=jsonpath='{.status.loadBalancer.ingress[0].ip}' \
   | awk '{print $1 " cluster.kty.dev"}' \
   | sudo tee -a /etc/hosts
@@ -113,7 +113,7 @@ kubectl -n kty get service server --output=jsonpath='{.status.loadBalancer.ingre
 If the load balancer isn't getting a public IP address, there's other ways to
 connect to the server. You can port forward using `kubectl`:
 
-```bash
+```bash copy
 kubectl -n kty port-forward service/server 2222:2222
 ```
 
@@ -124,7 +124,7 @@ see what you can do with kty.
 
 ## Test it out
 
-```bash
+```bash copy
 ssh -p 2222 me@cluster.kty.dev
 ```
 
@@ -136,7 +136,7 @@ ssh -p 2222 me@cluster.kty.dev
 
 - `scp` some files out of a container:
 
-  ```bash
+  ```bash copy
   scp -P 2222 me@cluster.kty.dev:/default/my-pod/etc/hosts /tmp
   ```
 

docs/pages/installation/helm.mdx

@@ -5,7 +5,7 @@ import { Callout } from 'nextra/components'
 There is a provided `getting-started.yaml` set of values. To install this on
 your cluster, you can run:
 
-```bash
+```bash copy
 helm install kty oci://ghcr.io/grampelberg/helm/kty \
   -n kty --create-namespace \
   --version $(curl -L https://api.github.com/repos/grampelberg/kty/tags | jq -r '.[0].name' | cut -c2-) \
@@ -15,7 +15,7 @@ helm install kty oci://ghcr.io/grampelberg/helm/kty \
 Note: this exposes the kty service externally by default. To get that IP
 address, you can run:
 
-```bash
+```bash copy
 kubectl -n kty get service server --output=jsonpath='{.status.loadBalancer.ingress[0].ip}'
 ```
 

docs/pages/usage.mdx

@@ -4,7 +4,7 @@
 
 To get to the dashboard, you can run:
 
-```bash
+```bash copy
 ssh anything@my-remote-host-or-ip -p 2222
 ```
 
@@ -19,7 +19,7 @@ cluster. The supported resources are `nodes`, `pods` and `services`. See the
 
 To forward port 9090 on your local system to 80 on the cluster, you can run:
 
-```bash
+```bash copy
 ssh me@my-cluster -p 2222 -L 9090:service/default/remote-service:80
 ```
 
@@ -32,13 +32,13 @@ not namespaced, the format is `<resource>/<name>`.
 Unlike the API server proxy, this works for any TCP service and is not limited
 to HTTP/HTTPS. For example, you can ssh directly to a node in the cluster with:
 
-```bash
+```bash copy
 ssh me@my-cluster -p 2222 -L 3333:no/my-node:22
 ```
 
 With that running in one terminal, you can run this in another:
 
-```bash
+```bash copy
 ssh my-node-username@localhost -p 3333
 ```
 
@@ -49,7 +49,7 @@ You can forward a remote service on your cluster to a port on your local host.
 To forward port 8080 on service `default/kty` to port `9090` on your local
 system, you can run:
 
-```bash
+```bash copy
 ssh me@my-cluster -p 2222 -R default/kty:8080:localhost:9090
 ```
 
@@ -59,13 +59,13 @@ The format for service definitions is `<namespace>/<service-name>`.
 
 The cluster is represented by a file tree:
 
-```bash
+```bash copy
 /<namespace>/<pod-name>/<container-name>/<file-path>
 ```
 
 For the `nginx` pod running in `default`, you would do something like:
 
-```bash
+```bash copy
 scp -P 2222 me@localhost:/default/nginx/nginx/etc/hosts /tmp
 ```