Handle non-root Kubernetes exec user context#113
Conversation
cc8f6be to
dc20c10
Compare
PR #113 Review: Handle non-root Kubernetes exec user contextExecutive SummaryThis PR refactors Kubernetes exec/attach to dynamically detect the running user instead of unconditionally wrapping every command in Critical Issues1. Unsanitized annotation value flows into shell command (Medium-High Severity)File:
While // Current code — no validation
func execTargetUsername(pod *corev1.Pod) string {
if pod != nil {
if u := strings.TrimSpace(pod.Annotations["scion.username"]); u != "" {
return u
}
}
return "scion"
}Suggested Fix: import "regexp"
var validUsername = regexp.MustCompile(`^[a-z_][a-z0-9_-]{0,31}$`)
func execTargetUsername(pod *corev1.Pod) string {
if pod != nil {
if u := strings.TrimSpace(pod.Annotations["scion.username"]); u != "" && validUsername.MatchString(u) {
return u
}
}
return "scion"
}2.
|
dc20c10 to
f304bd3
Compare
|
Addressed the annotation-safety feedback on this branch. Changes:
Validation:
|
PR-113 Review: Handle non-root Kubernetes exec user contextExecutive SummaryThis PR replaces a hardcoded Critical Issues1. Extra API round-trip on every Exec/Attach callFile: Every call to
The Severity: Medium — not blocking, but worth considering caching the result for the lifetime of the pod (the exec user won't change while a container is running). Suggested mitigation: // Cache on KubernetesRuntime, keyed by namespace/podName.
// Invalidate on pod restart (detectable via pod UID or resourceVersion).
type execUserCacheEntry struct {
user string
resourceVersion string
}2.
|
|
@mfreeman451 Let me know your thoughts on the cache idea if you think it is worth it. My concern is that trip could be multi hop like: Hub → Broker → GKE API server → kubelet on node |
I think caching makes sense here, will whip something up. |
* feat: chat channel routing for broker plugins (#113) Add channel-aware message routing so broker plugins (Telegram, Google Chat, etc.) can tag messages with a channel name and optional thread ID. The FanOutEventBus routes channel-tagged messages only to the matching bus and the in-process bus, while untagged messages fan out to all buses as before. Includes CLI --channel/--thread-id flags, a /message-channels API endpoint, and client library support. * fix: make channel-targeted publish concurrent and reject reserved inprocess channel - Channel-targeted messages now publish to InProcessBus and the matched channel concurrently (via goroutines), preventing slow external RPC calls from blocking HTTP handlers - Reject msg.Channel="inprocess" with a clear error — inprocess is a reserved internal bus, not a user-visible channel - Unmatched channels now fail fast before publishing to any bus - Add test for reserved inprocess channel rejection * fix: respect Observer flag in channel-targeted routing and validate outbound messages - Channel-targeted publish now checks target.Observer: observer channel errors are logged but not returned, consistent with the fan-out path - Add StructuredMessage.Validate() call in handleAgentOutboundMessage before publishing, catching invalid Channel/ThreadID combinations - Add test for observer error suppression in channel-targeted path
* feat: chat channel routing for broker plugins (GoogleCloudPlatform#113) Add channel-aware message routing so broker plugins (Telegram, Google Chat, etc.) can tag messages with a channel name and optional thread ID. The FanOutEventBus routes channel-tagged messages only to the matching bus and the in-process bus, while untagged messages fan out to all buses as before. Includes CLI --channel/--thread-id flags, a /message-channels API endpoint, and client library support. * fix: make channel-targeted publish concurrent and reject reserved inprocess channel - Channel-targeted messages now publish to InProcessBus and the matched channel concurrently (via goroutines), preventing slow external RPC calls from blocking HTTP handlers - Reject msg.Channel="inprocess" with a clear error — inprocess is a reserved internal bus, not a user-visible channel - Unmatched channels now fail fast before publishing to any bus - Add test for reserved inprocess channel rejection * fix: respect Observer flag in channel-targeted routing and validate outbound messages - Channel-targeted publish now checks target.Observer: observer channel errors are logged but not returned, consistent with the fan-out path - Add StructuredMessage.Validate() call in handleAgentOutboundMessage before publishing, catching invalid Channel/ThreadID combinations - Add test for observer error suppression in channel-targeted path
Summary
su - scionscion.usernameannotation when choosing the target user for execsTesting
Validation
scionondonbotscion lookreturns terminal output instead of failing withsu: Authentication failure