Try to minimize the scope of sudo use in scripts that require it by solsson · Pull Request #82 · Yolean/ystack

solsson · 2026-08-31T07:44:50Z

y-kubefwd and y-k8s-ingress-hosts do need the sudo, but should do as little as possible as sudo, in particular avoid kubectl because it might authenticate as the user.

Note that this means that kubefwd to GKE has only a 1hr lifetime. I think that's a feature.

The script ran the whole k8s-ingress-hosts binary under sudo, so every /etc/hosts update read the cluster as root: root ran gke-gcloud-auth-plugin, which ran gcloud, which left root-owned files in the invoking user's ~/.config/gcloud and ~/.kube. The binary has a -host-file flag, so the merge can happen on a copy as the invoking user and only the resulting file needs privilege. The new y-etc-hosts-write takes no arguments, refuses input that is empty or has no 127.0.0.1 entry, and swaps the file in with rename(2) so a reader never sees a half-written /etc/hosts. That also closes an escalation. The NOPASSWD rule granted $YBIN/y-k8s-ingress-hosts-v*-bin * and -host-file turns those wildcards into a write-any-file-as-root grant, e.g. -host-file /etc/sudoers.d/x -write. Also fixes a pre-existing set -e abort: grep -c prints 0 but exits 1 when no GatewayClass carries yolean.se/dns-hint-ip, which killed the script before it could fall back to the legacy annotation. No flag or exit code changes. Help migrated to the YHELP/help-subcommand convention. Verified against a stub binary: -check reports drift and exits 1, --ensure writes and is then idempotent, a no-flag run still previews entries, and Y_ETC_HOSTS makes the whole path testable without root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubefwd itself cannot avoid root. Upstream 1.25.16 says so in its own help text -- "kubefwd needs sudo for /etc/hosts and network interfaces" -- and its only no-sudo path is the mcp subcommand talking to an already-escalated instance over the REST API. But sudo -E handed root the entire environment: KUBECONFIG, HOME and PATH. Root therefore ran gke-gcloud-auth-plugin and gcloud, which is what put root-owned files under the user's ~/.kube and ~/.config/gcloud, and made every token refresh a root-run gcloud. Now the script generates a kubeconfig minified to the context and rewrites its exec credential to drop back to the invoking user (sudo -u USER -H), so the forwarder is the only thing running as root and all it ever receives is a bearer token. Contexts without an exec block (client certs, local clusters) pass through untouched. Preflight runs as the user so an expired login is reported in your own session instead of from inside the root process. The env hop in those exec args is load-bearing: sudo resets PATH to secure_path, where the plugin fails with exec: "gcloud": executable file not found in $PATH so PATH is restored to the plugin's own directory, where gcloud is a sibling. 1.25.12 -> 1.25.16 also brings idle mode: with no -n/-A kubefwd now starts its REST API and waits instead of forwarding, which the script now says out loud rather than looking hung. Running the script itself as root is refused, and the already-running guard exits 10 with pgrep -l (BSD pgrep has no -a). Verified with a stub sudo: argument assembly, the generated credential, that the rewritten exec command really returns an ExecCredential, and that 1.25.16 accepts our flags ahead of the svc subcommand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit kept the exec plugin in the kubeconfig and only moved it back to the invoking user with sudo -u. Root still drove it, and kubefwd re-invokes the credential every minute or two (552 config-helper calls on 2026-08-11, 1071 on 08-12), so every one of those became a sudo as well. It also left a gcloud-shaped hop in a script that has no business knowing about gcloud. Resolve the credential here instead, once, as the invoking user, and give kubefwd a kubeconfig holding only the token that came back. This is the client-go exec protocol, so nothing about it is gcloud specific: args, env and KUBERNETES_EXEC_INFO all come from the context's own exec block, whatever plugin it names. Contexts without one, client certificates on local clusters or a static token, pass through untouched, and that is also where the long sessions happen. The trade is now stated instead of implicit: a GKE token lasts an hour and is not renewed for a running kubefwd, so its expiry is printed at startup. Two details worth keeping: - The exec block has to be dropped, not just overwritten with a token. kubectl keeps both and exec wins. Done with a fresh user entry plus a re-minify, because unsetting users.NAME.exec needs a dotted path that breaks on user names containing dots. - Plugin stderr is captured separately. Folding it into stdout corrupts the ExecCredential of any plugin that warns while succeeding, which a stub reproduced. Verified with stub plugins: the token path, a failing plugin, a plugin answering with client certificates, that KUBERNETES_EXEC_INFO arrives well-formed, and that a client-certificate context reaches kubefwd unchanged. No cluster was contacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

solsson · 2026-08-31T07:44:50Z

y-kubefwd and y-k8s-ingress-hosts do need the sudo, but should do as little as possible as sudo, in particular avoid kubectl because it might authenticate as the user.

Note that this means that kubefwd to GKE has only a 1hr lifetime. I think that's a feature.

The script ran the whole k8s-ingress-hosts binary under sudo, so every /etc/hosts update read the cluster as root: root ran gke-gcloud-auth-plugin, which ran gcloud, which left root-owned files in the invoking user's ~/.config/gcloud and ~/.kube. The binary has a -host-file flag, so the merge can happen on a copy as the invoking user and only the resulting file needs privilege. The new y-etc-hosts-write takes no arguments, refuses input that is empty or has no 127.0.0.1 entry, and swaps the file in with rename(2) so a reader never sees a half-written /etc/hosts. That also closes an escalation. The NOPASSWD rule granted $YBIN/y-k8s-ingress-hosts-v*-bin * and -host-file turns those wildcards into a write-any-file-as-root grant, e.g. -host-file /etc/sudoers.d/x -write. Also fixes a pre-existing set -e abort: grep -c prints 0 but exits 1 when no GatewayClass carries yolean.se/dns-hint-ip, which killed the script before it could fall back to the legacy annotation. No flag or exit code changes. Help migrated to the YHELP/help-subcommand convention. Verified against a stub binary: -check reports drift and exits 1, --ensure writes and is then idempotent, a no-flag run still previews entries, and Y_ETC_HOSTS makes the whole path testable without root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubefwd itself cannot avoid root. Upstream 1.25.16 says so in its own help text -- "kubefwd needs sudo for /etc/hosts and network interfaces" -- and its only no-sudo path is the mcp subcommand talking to an already-escalated instance over the REST API. But sudo -E handed root the entire environment: KUBECONFIG, HOME and PATH. Root therefore ran gke-gcloud-auth-plugin and gcloud, which is what put root-owned files under the user's ~/.kube and ~/.config/gcloud, and made every token refresh a root-run gcloud. Now the script generates a kubeconfig minified to the context and rewrites its exec credential to drop back to the invoking user (sudo -u USER -H), so the forwarder is the only thing running as root and all it ever receives is a bearer token. Contexts without an exec block (client certs, local clusters) pass through untouched. Preflight runs as the user so an expired login is reported in your own session instead of from inside the root process. The env hop in those exec args is load-bearing: sudo resets PATH to secure_path, where the plugin fails with exec: "gcloud": executable file not found in $PATH so PATH is restored to the plugin's own directory, where gcloud is a sibling. 1.25.12 -> 1.25.16 also brings idle mode: with no -n/-A kubefwd now starts its REST API and waits instead of forwarding, which the script now says out loud rather than looking hung. Running the script itself as root is refused, and the already-running guard exits 10 with pgrep -l (BSD pgrep has no -a). Verified with a stub sudo: argument assembly, the generated credential, that the rewritten exec command really returns an ExecCredential, and that 1.25.16 accepts our flags ahead of the svc subcommand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit kept the exec plugin in the kubeconfig and only moved it back to the invoking user with sudo -u. Root still drove it, and kubefwd re-invokes the credential every minute or two (552 config-helper calls on 2026-08-11, 1071 on 08-12), so every one of those became a sudo as well. It also left a gcloud-shaped hop in a script that has no business knowing about gcloud. Resolve the credential here instead, once, as the invoking user, and give kubefwd a kubeconfig holding only the token that came back. This is the client-go exec protocol, so nothing about it is gcloud specific: args, env and KUBERNETES_EXEC_INFO all come from the context's own exec block, whatever plugin it names. Contexts without one, client certificates on local clusters or a static token, pass through untouched, and that is also where the long sessions happen. The trade is now stated instead of implicit: a GKE token lasts an hour and is not renewed for a running kubefwd, so its expiry is printed at startup. Two details worth keeping: - The exec block has to be dropped, not just overwritten with a token. kubectl keeps both and exec wins. Done with a fresh user entry plus a re-minify, because unsetting users.NAME.exec needs a dotted path that breaks on user names containing dots. - Plugin stderr is captured separately. Folding it into stdout corrupts the ExecCredential of any plugin that warns while succeeding, which a stub reproduced. Verified with stub plugins: the token path, a failing plugin, a plugin answering with client certificates, that KUBERNETES_EXEC_INFO arrives well-formed, and that a client-certificate context reaches kubefwd unchanged. No cluster was contacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

solsson · 2026-08-31T07:44:50Z

y-kubefwd and y-k8s-ingress-hosts do need the sudo, but should do as little as possible as sudo, in particular avoid kubectl because it might authenticate as the user.

Note that this means that kubefwd to GKE has only a 1hr lifetime. I think that's a feature.

The script ran the whole k8s-ingress-hosts binary under sudo, so every /etc/hosts update read the cluster as root: root ran gke-gcloud-auth-plugin, which ran gcloud, which left root-owned files in the invoking user's ~/.config/gcloud and ~/.kube. The binary has a -host-file flag, so the merge can happen on a copy as the invoking user and only the resulting file needs privilege. The new y-etc-hosts-write takes no arguments, refuses input that is empty or has no 127.0.0.1 entry, and swaps the file in with rename(2) so a reader never sees a half-written /etc/hosts. That also closes an escalation. The NOPASSWD rule granted $YBIN/y-k8s-ingress-hosts-v*-bin * and -host-file turns those wildcards into a write-any-file-as-root grant, e.g. -host-file /etc/sudoers.d/x -write. Also fixes a pre-existing set -e abort: grep -c prints 0 but exits 1 when no GatewayClass carries yolean.se/dns-hint-ip, which killed the script before it could fall back to the legacy annotation. No flag or exit code changes. Help migrated to the YHELP/help-subcommand convention. Verified against a stub binary: -check reports drift and exits 1, --ensure writes and is then idempotent, a no-flag run still previews entries, and Y_ETC_HOSTS makes the whole path testable without root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubefwd itself cannot avoid root. Upstream 1.25.16 says so in its own help text -- "kubefwd needs sudo for /etc/hosts and network interfaces" -- and its only no-sudo path is the mcp subcommand talking to an already-escalated instance over the REST API. But sudo -E handed root the entire environment: KUBECONFIG, HOME and PATH. Root therefore ran gke-gcloud-auth-plugin and gcloud, which is what put root-owned files under the user's ~/.kube and ~/.config/gcloud, and made every token refresh a root-run gcloud. Now the script generates a kubeconfig minified to the context and rewrites its exec credential to drop back to the invoking user (sudo -u USER -H), so the forwarder is the only thing running as root and all it ever receives is a bearer token. Contexts without an exec block (client certs, local clusters) pass through untouched. Preflight runs as the user so an expired login is reported in your own session instead of from inside the root process. The env hop in those exec args is load-bearing: sudo resets PATH to secure_path, where the plugin fails with exec: "gcloud": executable file not found in $PATH so PATH is restored to the plugin's own directory, where gcloud is a sibling. 1.25.12 -> 1.25.16 also brings idle mode: with no -n/-A kubefwd now starts its REST API and waits instead of forwarding, which the script now says out loud rather than looking hung. Running the script itself as root is refused, and the already-running guard exits 10 with pgrep -l (BSD pgrep has no -a). Verified with a stub sudo: argument assembly, the generated credential, that the rewritten exec command really returns an ExecCredential, and that 1.25.16 accepts our flags ahead of the svc subcommand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit kept the exec plugin in the kubeconfig and only moved it back to the invoking user with sudo -u. Root still drove it, and kubefwd re-invokes the credential every minute or two (552 config-helper calls on 2026-08-11, 1071 on 08-12), so every one of those became a sudo as well. It also left a gcloud-shaped hop in a script that has no business knowing about gcloud. Resolve the credential here instead, once, as the invoking user, and give kubefwd a kubeconfig holding only the token that came back. This is the client-go exec protocol, so nothing about it is gcloud specific: args, env and KUBERNETES_EXEC_INFO all come from the context's own exec block, whatever plugin it names. Contexts without one, client certificates on local clusters or a static token, pass through untouched, and that is also where the long sessions happen. The trade is now stated instead of implicit: a GKE token lasts an hour and is not renewed for a running kubefwd, so its expiry is printed at startup. Two details worth keeping: - The exec block has to be dropped, not just overwritten with a token. kubectl keeps both and exec wins. Done with a fresh user entry plus a re-minify, because unsetting users.NAME.exec needs a dotted path that breaks on user names containing dots. - Plugin stderr is captured separately. Folding it into stdout corrupts the ExecCredential of any plugin that warns while succeeding, which a stub reproduced. Verified with stub plugins: the token path, a failing plugin, a plugin answering with client certificates, that KUBERNETES_EXEC_INFO arrives well-formed, and that a client-certificate context reaches kubefwd unchanged. No cluster was contacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

solsson · 2026-08-31T07:44:50Z

y-kubefwd and y-k8s-ingress-hosts do need the sudo, but should do as little as possible as sudo, in particular avoid kubectl because it might authenticate as the user.

Note that this means that kubefwd to GKE has only a 1hr lifetime. I think that's a feature.

The script ran the whole k8s-ingress-hosts binary under sudo, so every /etc/hosts update read the cluster as root: root ran gke-gcloud-auth-plugin, which ran gcloud, which left root-owned files in the invoking user's ~/.config/gcloud and ~/.kube. The binary has a -host-file flag, so the merge can happen on a copy as the invoking user and only the resulting file needs privilege. The new y-etc-hosts-write takes no arguments, refuses input that is empty or has no 127.0.0.1 entry, and swaps the file in with rename(2) so a reader never sees a half-written /etc/hosts. That also closes an escalation. The NOPASSWD rule granted $YBIN/y-k8s-ingress-hosts-v*-bin * and -host-file turns those wildcards into a write-any-file-as-root grant, e.g. -host-file /etc/sudoers.d/x -write. Also fixes a pre-existing set -e abort: grep -c prints 0 but exits 1 when no GatewayClass carries yolean.se/dns-hint-ip, which killed the script before it could fall back to the legacy annotation. No flag or exit code changes. Help migrated to the YHELP/help-subcommand convention. Verified against a stub binary: -check reports drift and exits 1, --ensure writes and is then idempotent, a no-flag run still previews entries, and Y_ETC_HOSTS makes the whole path testable without root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubefwd itself cannot avoid root. Upstream 1.25.16 says so in its own help text -- "kubefwd needs sudo for /etc/hosts and network interfaces" -- and its only no-sudo path is the mcp subcommand talking to an already-escalated instance over the REST API. But sudo -E handed root the entire environment: KUBECONFIG, HOME and PATH. Root therefore ran gke-gcloud-auth-plugin and gcloud, which is what put root-owned files under the user's ~/.kube and ~/.config/gcloud, and made every token refresh a root-run gcloud. Now the script generates a kubeconfig minified to the context and rewrites its exec credential to drop back to the invoking user (sudo -u USER -H), so the forwarder is the only thing running as root and all it ever receives is a bearer token. Contexts without an exec block (client certs, local clusters) pass through untouched. Preflight runs as the user so an expired login is reported in your own session instead of from inside the root process. The env hop in those exec args is load-bearing: sudo resets PATH to secure_path, where the plugin fails with exec: "gcloud": executable file not found in $PATH so PATH is restored to the plugin's own directory, where gcloud is a sibling. 1.25.12 -> 1.25.16 also brings idle mode: with no -n/-A kubefwd now starts its REST API and waits instead of forwarding, which the script now says out loud rather than looking hung. Running the script itself as root is refused, and the already-running guard exits 10 with pgrep -l (BSD pgrep has no -a). Verified with a stub sudo: argument assembly, the generated credential, that the rewritten exec command really returns an ExecCredential, and that 1.25.16 accepts our flags ahead of the svc subcommand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit kept the exec plugin in the kubeconfig and only moved it back to the invoking user with sudo -u. Root still drove it, and kubefwd re-invokes the credential every minute or two (552 config-helper calls on 2026-08-11, 1071 on 08-12), so every one of those became a sudo as well. It also left a gcloud-shaped hop in a script that has no business knowing about gcloud. Resolve the credential here instead, once, as the invoking user, and give kubefwd a kubeconfig holding only the token that came back. This is the client-go exec protocol, so nothing about it is gcloud specific: args, env and KUBERNETES_EXEC_INFO all come from the context's own exec block, whatever plugin it names. Contexts without one, client certificates on local clusters or a static token, pass through untouched, and that is also where the long sessions happen. The trade is now stated instead of implicit: a GKE token lasts an hour and is not renewed for a running kubefwd, so its expiry is printed at startup. Two details worth keeping: - The exec block has to be dropped, not just overwritten with a token. kubectl keeps both and exec wins. Done with a fresh user entry plus a re-minify, because unsetting users.NAME.exec needs a dotted path that breaks on user names containing dots. - Plugin stderr is captured separately. Folding it into stdout corrupts the ExecCredential of any plugin that warns while succeeding, which a stub reproduced. Verified with stub plugins: the token path, a failing plugin, a plugin answering with client certificates, that KUBERNETES_EXEC_INFO arrives well-formed, and that a client-certificate context reaches kubefwd unchanged. No cluster was contacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

solsson · 2026-08-31T07:44:50Z

y-kubefwd and y-k8s-ingress-hosts do need the sudo, but should do as little as possible as sudo, in particular avoid kubectl because it might authenticate as the user.

Note that this means that kubefwd to GKE has only a 1hr lifetime. I think that's a feature.

The script ran the whole k8s-ingress-hosts binary under sudo, so every /etc/hosts update read the cluster as root: root ran gke-gcloud-auth-plugin, which ran gcloud, which left root-owned files in the invoking user's ~/.config/gcloud and ~/.kube. The binary has a -host-file flag, so the merge can happen on a copy as the invoking user and only the resulting file needs privilege. The new y-etc-hosts-write takes no arguments, refuses input that is empty or has no 127.0.0.1 entry, and swaps the file in with rename(2) so a reader never sees a half-written /etc/hosts. That also closes an escalation. The NOPASSWD rule granted $YBIN/y-k8s-ingress-hosts-v*-bin * and -host-file turns those wildcards into a write-any-file-as-root grant, e.g. -host-file /etc/sudoers.d/x -write. Also fixes a pre-existing set -e abort: grep -c prints 0 but exits 1 when no GatewayClass carries yolean.se/dns-hint-ip, which killed the script before it could fall back to the legacy annotation. No flag or exit code changes. Help migrated to the YHELP/help-subcommand convention. Verified against a stub binary: -check reports drift and exits 1, --ensure writes and is then idempotent, a no-flag run still previews entries, and Y_ETC_HOSTS makes the whole path testable without root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubefwd itself cannot avoid root. Upstream 1.25.16 says so in its own help text -- "kubefwd needs sudo for /etc/hosts and network interfaces" -- and its only no-sudo path is the mcp subcommand talking to an already-escalated instance over the REST API. But sudo -E handed root the entire environment: KUBECONFIG, HOME and PATH. Root therefore ran gke-gcloud-auth-plugin and gcloud, which is what put root-owned files under the user's ~/.kube and ~/.config/gcloud, and made every token refresh a root-run gcloud. Now the script generates a kubeconfig minified to the context and rewrites its exec credential to drop back to the invoking user (sudo -u USER -H), so the forwarder is the only thing running as root and all it ever receives is a bearer token. Contexts without an exec block (client certs, local clusters) pass through untouched. Preflight runs as the user so an expired login is reported in your own session instead of from inside the root process. The env hop in those exec args is load-bearing: sudo resets PATH to secure_path, where the plugin fails with exec: "gcloud": executable file not found in $PATH so PATH is restored to the plugin's own directory, where gcloud is a sibling. 1.25.12 -> 1.25.16 also brings idle mode: with no -n/-A kubefwd now starts its REST API and waits instead of forwarding, which the script now says out loud rather than looking hung. Running the script itself as root is refused, and the already-running guard exits 10 with pgrep -l (BSD pgrep has no -a). Verified with a stub sudo: argument assembly, the generated credential, that the rewritten exec command really returns an ExecCredential, and that 1.25.16 accepts our flags ahead of the svc subcommand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit kept the exec plugin in the kubeconfig and only moved it back to the invoking user with sudo -u. Root still drove it, and kubefwd re-invokes the credential every minute or two (552 config-helper calls on 2026-08-11, 1071 on 08-12), so every one of those became a sudo as well. It also left a gcloud-shaped hop in a script that has no business knowing about gcloud. Resolve the credential here instead, once, as the invoking user, and give kubefwd a kubeconfig holding only the token that came back. This is the client-go exec protocol, so nothing about it is gcloud specific: args, env and KUBERNETES_EXEC_INFO all come from the context's own exec block, whatever plugin it names. Contexts without one, client certificates on local clusters or a static token, pass through untouched, and that is also where the long sessions happen. The trade is now stated instead of implicit: a GKE token lasts an hour and is not renewed for a running kubefwd, so its expiry is printed at startup. Two details worth keeping: - The exec block has to be dropped, not just overwritten with a token. kubectl keeps both and exec wins. Done with a fresh user entry plus a re-minify, because unsetting users.NAME.exec needs a dotted path that breaks on user names containing dots. - Plugin stderr is captured separately. Folding it into stdout corrupts the ExecCredential of any plugin that warns while succeeding, which a stub reproduced. Verified with stub plugins: the token path, a failing plugin, a plugin answering with client certificates, that KUBERNETES_EXEC_INFO arrives well-formed, and that a client-certificate context reaches kubefwd unchanged. No cluster was contacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

solsson · 2026-08-31T07:44:50Z

y-kubefwd and y-k8s-ingress-hosts do need the sudo, but should do as little as possible as sudo, in particular avoid kubectl because it might authenticate as the user.

Note that this means that kubefwd to GKE has only a 1hr lifetime. I think that's a feature.

The script ran the whole k8s-ingress-hosts binary under sudo, so every /etc/hosts update read the cluster as root: root ran gke-gcloud-auth-plugin, which ran gcloud, which left root-owned files in the invoking user's ~/.config/gcloud and ~/.kube. The binary has a -host-file flag, so the merge can happen on a copy as the invoking user and only the resulting file needs privilege. The new y-etc-hosts-write takes no arguments, refuses input that is empty or has no 127.0.0.1 entry, and swaps the file in with rename(2) so a reader never sees a half-written /etc/hosts. That also closes an escalation. The NOPASSWD rule granted $YBIN/y-k8s-ingress-hosts-v*-bin * and -host-file turns those wildcards into a write-any-file-as-root grant, e.g. -host-file /etc/sudoers.d/x -write. Also fixes a pre-existing set -e abort: grep -c prints 0 but exits 1 when no GatewayClass carries yolean.se/dns-hint-ip, which killed the script before it could fall back to the legacy annotation. No flag or exit code changes. Help migrated to the YHELP/help-subcommand convention. Verified against a stub binary: -check reports drift and exits 1, --ensure writes and is then idempotent, a no-flag run still previews entries, and Y_ETC_HOSTS makes the whole path testable without root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubefwd itself cannot avoid root. Upstream 1.25.16 says so in its own help text -- "kubefwd needs sudo for /etc/hosts and network interfaces" -- and its only no-sudo path is the mcp subcommand talking to an already-escalated instance over the REST API. But sudo -E handed root the entire environment: KUBECONFIG, HOME and PATH. Root therefore ran gke-gcloud-auth-plugin and gcloud, which is what put root-owned files under the user's ~/.kube and ~/.config/gcloud, and made every token refresh a root-run gcloud. Now the script generates a kubeconfig minified to the context and rewrites its exec credential to drop back to the invoking user (sudo -u USER -H), so the forwarder is the only thing running as root and all it ever receives is a bearer token. Contexts without an exec block (client certs, local clusters) pass through untouched. Preflight runs as the user so an expired login is reported in your own session instead of from inside the root process. The env hop in those exec args is load-bearing: sudo resets PATH to secure_path, where the plugin fails with exec: "gcloud": executable file not found in $PATH so PATH is restored to the plugin's own directory, where gcloud is a sibling. 1.25.12 -> 1.25.16 also brings idle mode: with no -n/-A kubefwd now starts its REST API and waits instead of forwarding, which the script now says out loud rather than looking hung. Running the script itself as root is refused, and the already-running guard exits 10 with pgrep -l (BSD pgrep has no -a). Verified with a stub sudo: argument assembly, the generated credential, that the rewritten exec command really returns an ExecCredential, and that 1.25.16 accepts our flags ahead of the svc subcommand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit kept the exec plugin in the kubeconfig and only moved it back to the invoking user with sudo -u. Root still drove it, and kubefwd re-invokes the credential every minute or two (552 config-helper calls on 2026-08-11, 1071 on 08-12), so every one of those became a sudo as well. It also left a gcloud-shaped hop in a script that has no business knowing about gcloud. Resolve the credential here instead, once, as the invoking user, and give kubefwd a kubeconfig holding only the token that came back. This is the client-go exec protocol, so nothing about it is gcloud specific: args, env and KUBERNETES_EXEC_INFO all come from the context's own exec block, whatever plugin it names. Contexts without one, client certificates on local clusters or a static token, pass through untouched, and that is also where the long sessions happen. The trade is now stated instead of implicit: a GKE token lasts an hour and is not renewed for a running kubefwd, so its expiry is printed at startup. Two details worth keeping: - The exec block has to be dropped, not just overwritten with a token. kubectl keeps both and exec wins. Done with a fresh user entry plus a re-minify, because unsetting users.NAME.exec needs a dotted path that breaks on user names containing dots. - Plugin stderr is captured separately. Folding it into stdout corrupts the ExecCredential of any plugin that warns while succeeding, which a stub reproduced. Verified with stub plugins: the token path, a failing plugin, a plugin answering with client certificates, that KUBERNETES_EXEC_INFO arrives well-formed, and that a client-certificate context reaches kubefwd unchanged. No cluster was contacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

solsson · 2026-08-31T07:44:50Z

y-kubefwd and y-k8s-ingress-hosts do need the sudo, but should do as little as possible as sudo, in particular avoid kubectl because it might authenticate as the user.

Note that this means that kubefwd to GKE has only a 1hr lifetime. I think that's a feature.

The script ran the whole k8s-ingress-hosts binary under sudo, so every /etc/hosts update read the cluster as root: root ran gke-gcloud-auth-plugin, which ran gcloud, which left root-owned files in the invoking user's ~/.config/gcloud and ~/.kube. The binary has a -host-file flag, so the merge can happen on a copy as the invoking user and only the resulting file needs privilege. The new y-etc-hosts-write takes no arguments, refuses input that is empty or has no 127.0.0.1 entry, and swaps the file in with rename(2) so a reader never sees a half-written /etc/hosts. That also closes an escalation. The NOPASSWD rule granted $YBIN/y-k8s-ingress-hosts-v*-bin * and -host-file turns those wildcards into a write-any-file-as-root grant, e.g. -host-file /etc/sudoers.d/x -write. Also fixes a pre-existing set -e abort: grep -c prints 0 but exits 1 when no GatewayClass carries yolean.se/dns-hint-ip, which killed the script before it could fall back to the legacy annotation. No flag or exit code changes. Help migrated to the YHELP/help-subcommand convention. Verified against a stub binary: -check reports drift and exits 1, --ensure writes and is then idempotent, a no-flag run still previews entries, and Y_ETC_HOSTS makes the whole path testable without root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubefwd itself cannot avoid root. Upstream 1.25.16 says so in its own help text -- "kubefwd needs sudo for /etc/hosts and network interfaces" -- and its only no-sudo path is the mcp subcommand talking to an already-escalated instance over the REST API. But sudo -E handed root the entire environment: KUBECONFIG, HOME and PATH. Root therefore ran gke-gcloud-auth-plugin and gcloud, which is what put root-owned files under the user's ~/.kube and ~/.config/gcloud, and made every token refresh a root-run gcloud. Now the script generates a kubeconfig minified to the context and rewrites its exec credential to drop back to the invoking user (sudo -u USER -H), so the forwarder is the only thing running as root and all it ever receives is a bearer token. Contexts without an exec block (client certs, local clusters) pass through untouched. Preflight runs as the user so an expired login is reported in your own session instead of from inside the root process. The env hop in those exec args is load-bearing: sudo resets PATH to secure_path, where the plugin fails with exec: "gcloud": executable file not found in $PATH so PATH is restored to the plugin's own directory, where gcloud is a sibling. 1.25.12 -> 1.25.16 also brings idle mode: with no -n/-A kubefwd now starts its REST API and waits instead of forwarding, which the script now says out loud rather than looking hung. Running the script itself as root is refused, and the already-running guard exits 10 with pgrep -l (BSD pgrep has no -a). Verified with a stub sudo: argument assembly, the generated credential, that the rewritten exec command really returns an ExecCredential, and that 1.25.16 accepts our flags ahead of the svc subcommand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit kept the exec plugin in the kubeconfig and only moved it back to the invoking user with sudo -u. Root still drove it, and kubefwd re-invokes the credential every minute or two (552 config-helper calls on 2026-08-11, 1071 on 08-12), so every one of those became a sudo as well. It also left a gcloud-shaped hop in a script that has no business knowing about gcloud. Resolve the credential here instead, once, as the invoking user, and give kubefwd a kubeconfig holding only the token that came back. This is the client-go exec protocol, so nothing about it is gcloud specific: args, env and KUBERNETES_EXEC_INFO all come from the context's own exec block, whatever plugin it names. Contexts without one, client certificates on local clusters or a static token, pass through untouched, and that is also where the long sessions happen. The trade is now stated instead of implicit: a GKE token lasts an hour and is not renewed for a running kubefwd, so its expiry is printed at startup. Two details worth keeping: - The exec block has to be dropped, not just overwritten with a token. kubectl keeps both and exec wins. Done with a fresh user entry plus a re-minify, because unsetting users.NAME.exec needs a dotted path that breaks on user names containing dots. - Plugin stderr is captured separately. Folding it into stdout corrupts the ExecCredential of any plugin that warns while succeeding, which a stub reproduced. Verified with stub plugins: the token path, a failing plugin, a plugin answering with client certificates, that KUBERNETES_EXEC_INFO arrives well-formed, and that a client-certificate context reaches kubefwd unchanged. No cluster was contacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

solsson · 2026-08-31T07:44:50Z

y-kubefwd and y-k8s-ingress-hosts do need the sudo, but should do as little as possible as sudo, in particular avoid kubectl because it might authenticate as the user.

Note that this means that kubefwd to GKE has only a 1hr lifetime. I think that's a feature.

The script ran the whole k8s-ingress-hosts binary under sudo, so every /etc/hosts update read the cluster as root: root ran gke-gcloud-auth-plugin, which ran gcloud, which left root-owned files in the invoking user's ~/.config/gcloud and ~/.kube. The binary has a -host-file flag, so the merge can happen on a copy as the invoking user and only the resulting file needs privilege. The new y-etc-hosts-write takes no arguments, refuses input that is empty or has no 127.0.0.1 entry, and swaps the file in with rename(2) so a reader never sees a half-written /etc/hosts. That also closes an escalation. The NOPASSWD rule granted $YBIN/y-k8s-ingress-hosts-v*-bin * and -host-file turns those wildcards into a write-any-file-as-root grant, e.g. -host-file /etc/sudoers.d/x -write. Also fixes a pre-existing set -e abort: grep -c prints 0 but exits 1 when no GatewayClass carries yolean.se/dns-hint-ip, which killed the script before it could fall back to the legacy annotation. No flag or exit code changes. Help migrated to the YHELP/help-subcommand convention. Verified against a stub binary: -check reports drift and exits 1, --ensure writes and is then idempotent, a no-flag run still previews entries, and Y_ETC_HOSTS makes the whole path testable without root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kubefwd itself cannot avoid root. Upstream 1.25.16 says so in its own help text -- "kubefwd needs sudo for /etc/hosts and network interfaces" -- and its only no-sudo path is the mcp subcommand talking to an already-escalated instance over the REST API. But sudo -E handed root the entire environment: KUBECONFIG, HOME and PATH. Root therefore ran gke-gcloud-auth-plugin and gcloud, which is what put root-owned files under the user's ~/.kube and ~/.config/gcloud, and made every token refresh a root-run gcloud. Now the script generates a kubeconfig minified to the context and rewrites its exec credential to drop back to the invoking user (sudo -u USER -H), so the forwarder is the only thing running as root and all it ever receives is a bearer token. Contexts without an exec block (client certs, local clusters) pass through untouched. Preflight runs as the user so an expired login is reported in your own session instead of from inside the root process. The env hop in those exec args is load-bearing: sudo resets PATH to secure_path, where the plugin fails with exec: "gcloud": executable file not found in $PATH so PATH is restored to the plugin's own directory, where gcloud is a sibling. 1.25.12 -> 1.25.16 also brings idle mode: with no -n/-A kubefwd now starts its REST API and waits instead of forwarding, which the script now says out loud rather than looking hung. Running the script itself as root is refused, and the already-running guard exits 10 with pgrep -l (BSD pgrep has no -a). Verified with a stub sudo: argument assembly, the generated credential, that the rewritten exec command really returns an ExecCredential, and that 1.25.16 accepts our flags ahead of the svc subcommand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit kept the exec plugin in the kubeconfig and only moved it back to the invoking user with sudo -u. Root still drove it, and kubefwd re-invokes the credential every minute or two (552 config-helper calls on 2026-08-11, 1071 on 08-12), so every one of those became a sudo as well. It also left a gcloud-shaped hop in a script that has no business knowing about gcloud. Resolve the credential here instead, once, as the invoking user, and give kubefwd a kubeconfig holding only the token that came back. This is the client-go exec protocol, so nothing about it is gcloud specific: args, env and KUBERNETES_EXEC_INFO all come from the context's own exec block, whatever plugin it names. Contexts without one, client certificates on local clusters or a static token, pass through untouched, and that is also where the long sessions happen. The trade is now stated instead of implicit: a GKE token lasts an hour and is not renewed for a running kubefwd, so its expiry is printed at startup. Two details worth keeping: - The exec block has to be dropped, not just overwritten with a token. kubectl keeps both and exec wins. Done with a fresh user entry plus a re-minify, because unsetting users.NAME.exec needs a dotted path that breaks on user names containing dots. - Plugin stderr is captured separately. Folding it into stdout corrupts the ExecCredential of any plugin that warns while succeeding, which a stub reproduced. Verified with stub plugins: the token path, a failing plugin, a plugin answering with client certificates, that KUBERNETES_EXEC_INFO arrives well-formed, and that a client-certificate context reaches kubefwd unchanged. No cluster was contacted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

solssonand others added 3 commits August 31, 2026 07:36