This should be something we need to do next, but first I will help with business logic refactor before we start this.

How would #2 even work for clients using client certs? Without tokens and impersonation (even with tokens and impersonation) there are definitely some risks there. I guess I'm not horribly opposed to it (I like the idea of having an easy API for running GET), but what guarantees would we give for the API?

@smarterclayton My intention for 2. was to provide a sidecar bound to the loopback for applications running in the k8s cluster. If I understand correctly, this should only give access to the applications running in the same Pod, is that correct? I don't think this should be any less secure than running a kubectl proxy sidecar.

Oh, I was imagining a server endpoint that accepted Kube credentials and
invoked the appropriate kubectl command. I.e. something web consoles can
drop into easily (which could just be a shell window into a pod with exec).

On Mon, Aug 22, 2016 at 10:12 PM, Phillip Wittrock <notifications@github.com

wrote:

@smarterclayton https://github.com/smarterclayton My intention for 2.
was to provide a sidecar bound to the loopback for applications running in
the k8s cluster. If I understand correctly, this should only give access to
the applications running in the same Pod, is that correct? I don't think
this should be any less secure than running a kubectl proxy sidecar.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31173 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pzJTntgJPtY7KxwGGp1X8wQuPOr8ks5qilcmgaJpZM4JqXlJ
.

@smarterclayton Ah yes, I agree we would have to be more security conscious in that case. I think https://github.com/rancher/kubectld provides something along those lines. If we are successful with providing a sidecar we could probably extend (or reuse the majority of the work) to handle usages requiring stricter security.

I think kubectld give a good example of how to wrap kubectl, but definitely if we could a more elegant way to do this, it would be much convenient for third party tools to use kubectl.

@adohe Yes, the kubectld approach to wrapping kubectl is pretty simple. This issue could probably even be worked on in parallel by introducing a reasonable abstraction layer for invoking the kubectl logic. Work on them in whatever order makes the most sense to you.

We'd have to version kubectl pretty finely.

On Tue, Aug 23, 2016 at 11:25 AM, Phillip Wittrock <notifications@github.com

wrote:

@adohe https://github.com/AdoHe Yes, the kubectld approach to wrapping
kubectl is pretty simple. This issue could probably even be worked on in
parallel by introducing a reasonable abstraction layer for invoking the
kubectl logic. Work on them in whatever order makes the most sense to you.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31173 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pzZsWt1-pAsGd2t2hH5Fkn0SoYBuks5qixDfgaJpZM4JqXlJ
.

@smarterclayton Could you expand upon your comment?

In that changes to kubectl happen pretty often - we try to be backwards
compatible, but it's not perfect, and we don't preserve old behavior in all
cases. We also sometimes change behavior for new function. If we exposed
this via GRPC, I wouldn't want to have to continually evolve the GRPC API
based on kubectl - I'd almost expect it to be generated, and potentially be
incompatible from version to version. If someone wants to lock a version,
they could always lock to a particular kubectl version.

On Tue, Aug 23, 2016 at 5:09 PM, Phillip Wittrock notifications@github.com
wrote:

@smarterclayton https://github.com/smarterclayton Could you expand upon
your comment?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31173 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p8M0gJmt6hDa1DLbJ1_j4LvOSsDHks5qi2F4gaJpZM4JqXlJ
.

/sig cli

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

/remove-lifecycle rotten