SSH vs.kubectl exec

比较ssh和kubectl

让我们看一下打开远程shell的两种流行方法：ssh与kubectl exec。

下面，我们将只看“ kubectl exec”子命令及相关的命令。kubectl本身就是所有Kubernetes的瑞士军刀。。将所有这些与ssh进行比较就像将systemd与BSD init进行比较一样。

另外，我将使用“SSH”来表示“OpenSSH”，这是SSH协议实现的事实标准。但大多数讨论要点都适用于任何SSH实现。

Apples to Oranges

乍一看，这是一个奇怪的比较。

OpenSSH已经存在了二十年，远远早于云技术的 诞生。它的设计是假设您要管理几台服务器，并正在仔细配置和调整它们的各个方面。SSH也已被用作SFTP和Ansible之类的传输层协议。

另一方面，kubectl诞生于云时代。它处理成千上万的远程机器（或容器）。kubectl exec只是其中的一小部分，用于在出现问题时进行调试。

但是，如果您如果仔细观则会发现：kubectl exec与ssh目的相同。它可以在远程计算机上运行程序，而不会给您本地终端带来麻烦，并尝试与各种终端功能集成在一起，从而使您感觉好像已将键盘和显示器插入了数据中心机架。

顺便说一句，让我们深入探讨它们的异同。

Authn/z

让我们从每个人最喜欢的主题开始：安全性。

TL; DR：SSH身份验证非常容易定制，但是大规模管理很麻烦。kubectl处理授权要好得多，但是身份验证通常是不透明的，很难调整。

注意：这里我们不会讨论身份验证方法的优缺点，这是另外一个话题，我们下次再讨论。

SSH协议

SSH支持多种身份验证选项：

• 基本密码

• 非对称加密密钥

• • 以明文形式在磁盘上

  • 在使用密码加密的磁盘上

  • 使用硬件令牌（例如YubiKey）

• 证书（但不是X.509类型）链接到专用CA

• • 上面有用于存储私钥的所有选项

• 通过GSS AP或PAM的可插拔外部身份验证

• • 例如Active Directory，LDAP，OIDC等

• 2FA

• 基于本地的硬件令牌

• • 或通过PAM使用TOTP（例如Google Authenticator）或Duo等进行关联

要对服务器进行身份验证，您可以获得非对称公钥或证书。默认情况下，SSH使用首次使用信任（TOFU），因此作为预防措施，您可能希望在客户端计算机上管理〜/.ssh/known_hosts。

作为用户，您可以选择所需的身份验证方法以及如何在两侧进行配置！

当涉及授权时，情况并不理想。授权粒度基本上是：“ 用户X可以登录到服务器Y ”，没有分组。您必须通过将用户的公共密钥写入〜/.ssh/authorized_keys并为其创建本地UNIX用户，来配置用户可能分别登录的每个服务器。将CA与SSH证书一起使用可以帮助分发密钥。PAM管道也可以为您创建用户。无论如何，这将需要一些额外工作。

幸运的是，如果您愿意扩展工具，可以使用更高级别的软件来解决这些问题。

Kubectl

大多数时候，大家都会认为kubeconfig管理kubernetns中的所有凭证。当使用托管的Kubernetes平台，您甚至可能不会注意到平台后台会自动生成它。很少有人会直接修改kubeconfig内容，大多数情况下，您将使用云或身份验证提供程序生成的内容。

这是一个不错的用户体验，但下面有一些常见的问题点：

• HTTP基本身份验证（用户名+密码为纯文本）

• TLS客户端证书（磁盘上的私钥以纯文本格式）

• 不透明的令牌（在磁盘上以纯文本格式）

• 云提供商插件

• • 这些被编译成 kubectl code itself

  • 慢慢地逐步淘汰以减少Kubernetes代码依赖性

• Exec插件

<