/sig security
/triage accepted

Hello, I have a couple clarifying questions from my end:

• I’m lost in the weeds looking for the kubectl config Github location, I figured it’d be around here , where do I go to edit the kubectl config reference ?
• Is there an example of warnings in the reference site that I could follow in terms of formatting ?
• The Banzai article mentions adding warnings in Go SDK as well. I’m not too familiar with Go and this might be out of our scope, but where would I make the PR to Go SDK?
• Silly goose question but remote code injection is the same as shell injection right?

This will be my first PR in the project, all inputs are much appreciated ❤️️

For the last question... getting to really specific definitions of terms like those gets super complicated. :-)

In this case I wouldn't call it "injection" at all, because to me that implies a normal thing is happening and you are unexpectedly introducing your code where your code does not belong. SQL injection provides a great example of this usage: where you would put a datum such as your name, instead you put SQL code, and 🎉 your SQL code runs, and that's SQL injection.

I think I would just call it "code execution" or "command execution" or "shell command execution". They'll all mean the same thing in this context, and are all accurate, just depends on your writing style.

In general with exec credential provider, I wouldn't call it 'remote' because it's not always remote: the command execution happens wherever the kubeconfig is used. that could be local to your machine (e.g. somebody tricks you into running a kubeconfig that runs commands on your machine) or remote (e.g. you fool an automated system into running a kubeconfig that lets you run commands remotely) depending on the context. So you might say that Server Product Foo has a Remote Code Execution flaw due to handling untrusted kubeconfig files, but the feature itself is more general than that, it's just command or code execution.

please keep in touch and thanks for helping!

Hello! I created a PR here for the "Cluster Access" pages in Task and Concept. Still havent able to find the Github page for the generated reference page

PTAL. Specifically:

• Should the warning come before or after the note?
• Would it be useful/ appropriate to inlcude the Bonzai Cloud article in the warning? A simple search of "kubeconfig code execution" does bring it up.

Thanks! ❤️

Hello! I created a PR here for the "Cluster Access" pages in Task and Concept. Still havent able to find the Github page for the generated reference page

PTAL. Specifically:

* Should the `warning` come before or after the `note`?

@sftim @kbhawkey - is there any order of placement for adding notes and warnings?

* Would it be useful/ appropriate to inlcude the Bonzai Cloud article in the warning? A simple search of "kubeconfig code execution" does bring it up.

I am not sure about the right course of action here. If the link becomes unavailable then it will be a maintenance overhead. @tabbysable WDYT?

👀

Hi. @gracenng , the kubectl reference is auto-generated from the kubectl command descriptions/content.

* Should the `warning` come before or after the `note`?

I think it looks nice right now, with the warning after the note.

* Would it be useful/ appropriate to inlcude the Bonzai Cloud article in the warning? A simple search of "kubeconfig code execution" does bring it up.

I agree this is a complex question: it would be nice to offer further information, but linking to external resources we don't control gives the danger of the link going away in the future.
@kubernetes/sig-docs-en-reviews do you have any general guidance on external links in k8s documentation?

general guidance on external links in k8s documentation?

https://kubernetes.io/docs/contribute/style/content-guide/

The approach I'd prefer for this one is that we publish a similar article to https://banzaicloud.com/blog/kubeconfig-security/ but on the Kubernetes blog, and then we can hyperlink to that with no problems (plus if we ever need to retire / clarify said article, we can).

I can help anyone who's keen to write that new article. The easier option is not to link to any blog article but still document the risk,

Oh, one more thing. If we do write an article for https://blog.k8s.io/, we can and should credit the Banzai article as inspiration.

Hello, the PR for this issue has been merged.

Outstanding work:

• Consider adding the same warning to the reference page
• Discuss the potential of writing an article on this like @sftim mentioned. I'd be happy to help write it but I don't think I have the expertise

@GraceNg if you'd like to sketch out an article, I'd be happy to help you get it completed.

(feel free to ping me in #sig-docs on Kubernetes Slack, too)
If some pairing time or similar would help, I can try to schedule that in.

Thanks for the offer @sfabel I'll let you know

You may not have the expertise, but you can develop it!

I recommend playing with the ideas, writing a few malicious kubeconfig files, and trying them out on yourself and your willing friends and colleagues (I volunteer!). Then I think you'll feel much more comfortable writing an article that is more than just restating things from another article.

Once you start getting a draft together, I know several of us from both SIG Security and SIG Docs would love to help.

@tabbysable try writing my own malicious kubeconfig file is a wonderful suggestion and it certainly makes this less overwhelming. Would a bare-metal cluster be easier to work with compared to a cloud provider one here? Or is any kubeconfig file okay

@gracenng If you want, you could try to use kind or minikube - that way you don't need a cluster beyond one running on your PC.

+1 what Tim said. Technically speaking, you don't need any cluster at all. But, if you wanted to make a really cool one that pwnd your machine and actually worked, you'd want a cluster to test on. I'm partial to Kind for these sorts of things because it's so quick and easy.

This issue was resolved by merging #28248

Thanks so much!

/close

@tabbysable: Closing this issue.