Both SSH and kubectl handle terminal colors, escape codes, interactive commands and even window resize events. Luckily, SSO integrations are pretty decent on most hosted platforms. The “hardest” part is making sure every employee gets a kubeconfig with the right identity that your RBAC rules will match against. But when you’re done, you can say: " everyone in Engineering can log into staging (namespace) pods but only oncall can touch prod (namespace)". It takes some learning, copy-pasting YAML blobs from the Internet and tweaking them. All kubectl exec requests are funneled through the Kubernetes API server, which enforces RBAC rules. Kubernetes handles authorization natively, through RBAC. per-pod) design would fly here, because Kubernetes pods are ephemeral. Servers are authenticated using TLS, with a private CA usually embedded in kubeconfig.Īuthorization story here is much nicer than in SSH! No SSH-like (e.g. If you want 2FA, this is probably the way to go.Used by cloud providers to integrate with their bespoke authentication systems.On each request, executes an external binary to get a bearer token or TLS client key/cert.Getting slowly phased-out to reduce the Kubernetes code dependency spaghetti.These are compiled into the kubectl code itself.Opaque static (“bearer”) tokens (on disk in plaintext).TLS client certificates (with private key on disk in plaintext).HTTP basic authentication (username+password in plaintext).It’s a nice UX abstraction, but underneath there are the usual suspects: It’s very rare to tinker with kubeconfig contents directly, most of the time you’ll use whatever your cloud or authentication provider generates. With a managed Kubernetes platform, the provider will generate it and you may not even notice. Most of you will be familiar with kubeconfig as " The One Kubernetes credential to rule them all". Luckily, higher-level software is available to solve these problems if you’re willing to expand your toolbox. A bit of PAM plumbing can also create users for you. Using SSH certificates can help with key distribution. You have to configure each server a user might log into individually by writing users’ public keys to ~/.ssh/authorized_keys and creating a local UNIX user for them. Authorization granularity is basically: " user X can log into server Y," no grouping. When it comes to authorization, things are not great. By default, SSH uses trust on first use (TOFU), so you may want to manage ~/.ssh/known_hosts on client machines as a precaution.Īs a user, you get to choose which authn method you want and how to configure it on both sides - yay! To authenticate a server, you get either an asymmetric public key or a certificate. Google Authenticator) or services like Duo, through PAM Pluggable external authentication via GSSAPI and/or PAM.With all the options for storing a private key above.Certificates ( but not the X.509 kind!) linked to a private CA.SSH supports a range of authentication options: Note: we won’t discuss pros and cons of authentication methods here, that’s a yak for another shaving session. kubectl deals with authorization much better, but authentication is usually opaque and hard to tweak. TL DR: SSH authentication is very customizable, but large-scale management is a pain. Let’s start with everyone’s favorite topic: security. With that out of the way, let’s dive into their similarities and differences. Make it feel like you’ve plugged a keyboard and monitor into a datacenter rack. Your local terminal and tries to integrate with various terminal features, to It runs a program on a remote machine without leaving the comfort of However, if you step back and squint, kubectl exec serves the same purpose as kubectl exec is just a small part of this and is used for debugging when things go wrong. It deals with remote machines (or containers) by the thousands, treating them like cattle. Kubectl, on the other hand, was born in the cloud, molded by it. SSH has also been adopted as a transport-layer protocol for things like SFTP and Ansible. Its design assumes that you’re managing a handful of pet servers and are carefully configuring and tweaking every aspect of them. OpenSSH has been around for two decades, long before The Cloud was born. But most discussion points will apply to anyĪt first glance, this is an odd comparison. Of it to ssh is like comparing systemd to BSD init.Īlso, I will use SSH to mean OpenSSH, which is the de-facto standardįor SSH protocol implementation. Kubectl itself is a swiss-army knife for all things Kubernetes. Opening remote shells, similar to good ol’ ssh.īelow, I will only look at the kubectl exec subcommand and its friends. What is kubectl exec? It's a new and popular way of executing remote commands or
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |