mirror of
https://github.com/mulgadc/spinifex.git
synced 2026-10-15 17:11:30 +00:00
Josh Siviour
f14fb64562
* feat(eks): unify eks-server + eks-agent into one eks-node AMI Collapse the two K3s AMIs into a single spinifex-eks-node image whose role (server vs agent) is chosen per-instance at first boot, halving build time, storage, and CVE-rotation surface. - scripts/images/eks-node/: superset manifest + merged setup.sh; all role services baked but only crond + the new eks-node-role selector enabled. - eks-node-role first-boot selector reads SPINIFEX_K3S_ROLE, rc-update adds + starts the matching services (server: k3s + eks-token-webhook + k3s-first-boot publisher; agent: k3s-agent), records /etc/spinifex-eks/role, self-disables. Paths are env-overridable; eks-node-role_test.sh covers all five cases. - mulga-eks-etcd-snapshot.sh early-exits on agent nodes. - k3s_server_vm.go seeds SPINIFEX_K3S_ROLE=server into first-boot.env. - Makefile/dev-install: build-eks-node-image / import-eks-node-image replace the server+agent targets. - Delete scripts/images/eks-server + eks-agent. The launcher resolves the AMI by the spinifex:managed-by=eks tag, so running clusters (which hold the resolved AMI ID) are unaffected. AMI bake + cluster boot are operational integration steps, not yet run. * fix(eks): order eks-node-role after cloud-config/cloud-final The first-boot role selector reads /etc/spinifex-eks/first-boot.env, which cloud-init delivers via write_files in the cloud-config/cloud-final stages. The selector only depended on net+cgroups, so on a fast boot it could start before write_files landed and read a missing role env. Add an after-ordering on cloud-config + cloud-final so the env file is always present first.
37 lines
1.4 KiB
Plaintext
Executable File
37 lines
1.4 KiB
Plaintext
Executable File
#!/sbin/openrc-run
|
|
# eks-token-webhook — K8s TokenReview authenticator for IAM-backed kubectl.
|
|
# Binds 127.0.0.1:8443 only; kube-apiserver is the sole client (loopback path).
|
|
# Decodes `aws eks get-token` presigned URLs, verifies them via Mulga STS over
|
|
# NATS, and resolves the principal to a TokenReview via the cluster AccessEntry
|
|
# KV. Ordered `before k3s` so its apiserver kubeconfig exists before k3s reads
|
|
# --authentication-token-webhook-config-file.
|
|
|
|
description="EKS Token Review webhook (Mulga)"
|
|
command="/usr/local/bin/eks-token-webhook"
|
|
command_args="--addr=127.0.0.1:8443"
|
|
command_background="yes"
|
|
pidfile="/run/eks-token-webhook.pid"
|
|
output_log="/var/log/eks-token-webhook.log"
|
|
error_log="/var/log/eks-token-webhook.log"
|
|
|
|
# NATS creds + cluster identity come from the cloud-init-seeded first-boot env.
|
|
# Sourced here and exported so start-stop-daemon hands them to the binary, which
|
|
# reads SPINIFEX_NATS_* / EKS_ACCOUNT_ID / EKS_CLUSTER_NAME from its environment.
|
|
if [ -f /etc/spinifex-eks/first-boot.env ]; then
|
|
# shellcheck disable=SC1091
|
|
. /etc/spinifex-eks/first-boot.env
|
|
export SPINIFEX_NATS_URL SPINIFEX_NATS_TOKEN SPINIFEX_NATS_CA EKS_ACCOUNT_ID EKS_CLUSTER_NAME
|
|
fi
|
|
|
|
depend() {
|
|
need net
|
|
before k3s
|
|
}
|
|
|
|
start_pre() {
|
|
if [ ! -f /etc/spinifex-eks/first-boot.env ]; then
|
|
eerror "/etc/spinifex-eks/first-boot.env not present — cloud-init did not seed NATS creds"
|
|
return 1
|
|
fi
|
|
}
|