feat(install): adding resources install

Kustomize was just too difficult to get working
well in getting started. This introduces an
`install` and `delete` command that does it for
all resources, not just the CRD. There's some
minimal patching that happens to the resources so
that they hopefully can still be applied with
`kubectl` directly from the repo.

Author: grampelberg

Cargo.lock

@@ -25,6 +25,7 @@ categories = ["command-line-interface", "development-tools", "virtualization"]
 [dependencies]
 ansi-to-tui = "6.0.0"
 async-trait = "0.1.82"
+base64 = "0.22.1"
 bon = "2.2.1"
 cata = { version = "0.1.1" }
 chrono = { version = "0.4.38", features = ["serde"] }
@@ -37,13 +38,13 @@ crossterm = { version = "0.28.1", default-features = false, features = [
     "events",
 ] }
 derive_builder = { version = "0.20.1", features = ["clippy"] }
-either = "1.13.0"
 eyre = "0.6.12"
 fast_qr = "0.12.5"
 futures = "0.3.30"
 hostname = "0.4.0"
 humantime = "2.1.0"
 itertools = "0.13.0"
+json-patch = "2.0.0"
 json_value_merge = "2.0.0"
 jsonwebtoken = "9.3.0"
 k8s-openapi = { version = "0.22.0", features = ["earliest"] }
@@ -65,6 +66,7 @@ ringbuffer = "0.15.0"
 russh = "0.45.0"
 russh-keys = "0.45.0"
 russh-sftp = "2.0.3"
+rust-embed = "8.5.0"
 schemars = { version = "0.8.21", features = ["chrono"] }
 serde = { version = "1.0.210", features = ["derive"] }
 serde_json = "1.0.128"

Cargo.toml

@@ -89,3 +89,11 @@ If you're not running on the cluster, you'll want to:
 - Set `POD_UID` to the `metadata.uid` of the pod from `HOSTNAME`.
 - Set `POD_IP` to the IP address of your host. You can get this by going into a
   pod and doing a `nslookup host.docker.internal`.
+
+## Kubernetes Resources
+
+When updating resources, make sure to update them in both places:
+
+- [resources](/resources/) - Used for `kty resources`, primarily as part of
+  getting started.
+- [helm/templates](/helm/templates/) - Used for `helm install`

DEVELOPMENT.md

@@ -11,10 +11,6 @@
   particular, it seems like it is a little difficult to see the install commands
   and realize that's what you need to use.
 
-## `users grant`
-
-- Allow YAML output for users who don't have a `kubeconfig`.
-
 ## Authorization
 
 - Groups are probably what most users are going to want to use to configure all

TODO.md

@@ -1,52 +1,147 @@
+import { Callout } from 'nextra/components'
+
 # Getting Started
 
-1. Download the [cli][cli-download] and add it to your `$PATH`.
-1. Get a k8s cluster. [k3d][k3d] is a convenient way to get a cluster up and
-   running fast. Follow their installation instructions and create a default
-   cluster.
-1. Grant your email address access to the cluster. Choose `cluster-admin` if
-   you'd like something simple to check out how things work. For more details on
-   the minimum possible permissions, read the [Authorization][auth] section. The
-   email address is what you'll be using to authenticate against. It can either
-   be the one associated with a google or github account. Note, the ID used for
-   login and the providers available can all be configured.
+As part of this getting started guide, you will:
+
+- Grant your email address access to the cluster.
+- Install kty on your cluster.
+- Test it out!
+
+<Callout type="info">
+  You can run kty outside of a cluster, but it is a little more complex to get
+  setup because of permissions. Check out the
+  [off-cluster](/installation#off-cluster) instructions for more details.
+</Callout>
+
+## Prerequisites
+
+- Get a k8s cluster. [k3d][k3d] is a convenient way to get a cluster up and
+  running fast. Follow their installation instructions and create a default
+  cluster.
+
+## Install the CLI
+
+Binares are available on the [releases page][cli-download]. If you have
+homebrew, you can install with:
+
+```bash
+brew install grampelberg/kty/kty
+```
+
+<Callout type="info">
+  `ssh` is all you need to use kty. The CLI is optional, but makes installation
+  and management a little easier.
+</Callout>
+
+## Setup Permissions
+
+Just like `kubectl`, kty delegates authorization to Kubernetes RBAC. The email
+address you use to login needs to be granted access to the cluster. If your
+organization already uses email addresses for access, you can skip the install
+step - make sure you verify you've got access though.
+
+To grant access to your email, you can use the `kty` CLI. It will apply a
+`ClusteerRoleBinding` that associates your email address with the provided role.
+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
+kty users grant cluster-admin me@example.com
+```
+
+<Callout type="info">
+  If you'd like to verify the YAML or apply it youself, pass `-o yaml` to the
+  command.
+</Callout>
+
+You can verify that this worked and you have the minimum permissions required by
+running:
+
+```bash
+kty users check me@example.com
+```
 
-   ```bash
-   kty users grant <cluster-role> <email-address>
-   ```
+This command runs a `SelfSubjectAccessReview` against your cluster. If you want
+to use `kubectl` instead, you can run:
 
-1. Start the server.
+```bash
+kubectl auth can-i list pods --as me@example.com
+```
 
-   ```bash
-   kty --serve
-   ```
+## Install on your cluster
 
-1. SSH into your cluster!
+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
-   ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 2222 me@localhost
-   ```
+```bash
+kubectl create ns kty && \
+  kty resources install -n kty
+```
 
-From this point, here's a few suggestions for things to check out:
+<Callout type="info">
 
-- Start a new pod. It'll show up in the dashboard immediately!
+You can pass `--dry-run` to see what's happening or pass the output to
+`kubectl apply -f -` yourself. If you'd like to install using a different
+method, such as helm, see the [installation](/installation) instructions.
+
+To clean these resources up, you can run `kty resources delete -n kty`.
+
+</Callout>
+
+Verify that this is up and running successfully by checking that the pod has
+started up:
+
+```bash
+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:
+
+```bash
+kubectl -n kty get service server --output=jsonpath='{.status.loadBalancer.ingress[0].ip}'
+```
+
+<Callout type="warning">
+
+If the load balancer isn't getting a public IP address, there's other ways to
+connect to the server. On way is to port forward using `kubectl`:
+
+```bash
+kubectl -n kty port-forward service/server 2222:2222
+```
+
+This is not something you'd want to do in production, but it's a quick way to
+see what you can do with kty.
+
+</Callout>
+
+## Test it out
+
+```bash
+ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 2222 me@localhost
+```
+
+## Next Steps
 
 - Exec into a pod. Select the pod you want and go to the `Shell` tab. You'll be
   able to pick the command to exec and then be shell'd into the pod directly.
 
-- Follow the logs. Logs for all containers in a pod are streamed to the `Logs`
-  tab when you've selected a pod from the main list.
-
 - `scp` some files out of a container:
 
   ```bash
   scp -P 2222 me@localhost:/default/my-pod/etc/hosts /tmp
   ```
 
-- Use your own [OpenID provider](/installation#bring-your-own-provider).
+- Check out [usage](/usage) for more information on everything that you can do.
 
-Note: you'll want to install on-cluster to use the tunnelling functionality.
-Check out the [helm](/installation/helm) docs for a quick way to do that.
+- You can [bring your own provider](/installation#bring-your-own-provider) if
+  the default provider don't work for you. This would be a great way to
+  configure groups or use other types of logins if your organization uses
+  something other than Google or Github.
 
 [cli-download]: https://github.com/grampelberg/kty/releases
 [k3d]: https://k3d.io

docs/pages/getting-started.mdx

@@ -0,0 +1,9 @@
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: kty-server
+  labels:
+    app.kubernetes.io/component: server
+    app.kubernetes.io/name: kty-server
+    app.kubernetes.io/part-of: kty
+    app.kubernetes.io/managed-by: kty-cli

kustomize/kustomization.yaml

@@ -0,0 +1,17 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: kty-server
+  labels:
+    app.kubernetes.io/component: server
+    app.kubernetes.io/name: kty-server
+    app.kubernetes.io/part-of: kty
+    app.kubernetes.io/managed-by: kty-cli
+subjects:
+  - kind: ServiceAccount
+    name: kty-server
+    namespace: kty
+roleRef:
+  kind: ClusterRole
+  name: kty-server
+  apiGroup: rbac.authorization.k8s.io

resources/account.yaml

@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Secret
+metadata:
+  name: kty-server
+  labels:
+    app.kubernetes.io/component: server
+    app.kubernetes.io/name: server
+    app.kubernetes.io/part-of: kty
+    app.kubernetes.io/managed-by: kty-cli
+data:
+  placeholder: ''

resources/binding.yaml

@@ -1,10 +1,12 @@
----
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: kty-server
   labels:
     app.kubernetes.io/component: server
+    app.kubernetes.io/name: kty-server
+    app.kubernetes.io/part-of: kty
+    app.kubernetes.io/managed-by: kty-cli
 rules:
   - apiGroups: ['']
     resources:
@@ -27,17 +29,3 @@ rules:
       - patch
     resourceNames:
       - keys.kty.dev
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: kty-server
-  labels:
-    app.kubernetes.io/component: server
-subjects:
-  - kind: ServiceAccount
-    name: kty-server
-roleRef:
-  kind: ClusterRole
-  name: kty-server
-  apiGroup: rbac.authorization.k8s.io