jeffreystoke

@huangmingyou 是的，还支持从远程 http 服务拉取配置，以及 git ssh 仓库抽取配置（ renderer 文档部分）

同样的痛点, 我一直觉得 kustomize 的路走错了, helm 更适合需要大量动态调整的复杂部署 (可能是我看问题的高度不够?)

为了解决这个问题, 外加需要管理多个仓库里的 yaml 配置并且实现重用以便统一结果, 我自己开发了一个工具 dukkha, 但是目前还没有实际用到生产环境中 (项目地址: https://github.com/arhat-dev/dukkha )

对应到你的需求可以用 dukkha 这么管理:

首先给不同环境创建 host-alias.yml 文件

production 环境: inventory/production/host-alias.yml

```yaml
- hostnames:
- production-foo
ip: ...
```

dev 环境: inventory/dev/host-alias.yml

```yaml
- hostnames:
- dev-foo
ip: ...
```

```yaml
apiVersion: v1
kind: Pod
spec:
hostAliases@env|file: inventory/${ENVIRONMENT}/host-alias.yml
```

把目录结构建好, 然后在不同环境里面设置好 ENVIRONMENT 变量 (production/dev) 即可使用 `dukkha render` 进行渲染

有进一步了解需求的话, 可以看项目里的文档, 应该是够用的

另外如果想深入讨论相关内容的, 欢迎邮件到 aW5xdWlyaWVzQGFyaGF0LnNvbHV0aW9ucw== , 内容需要注明 v2 用户名以及一个可交叉验证身份的第三方平台链接 (如 github 用户链接)

@thxgod
@fkdtz
@zjccc

docker 直接跑 amd64 的话使用 qemu-static 模拟运行的, 如果主要做 amd64 开发克意考虑用 lima + qemu-system 装 amd64 虚拟机, 个人体验是 qemu-static 经常性出错, qemu-system + hvf 目前还没出过问题

fyi: lima: https://github.com/lima-vm/lima

@taobibi @Tianao @keith1126

如 @keith1126 #3 所说, 主要问题是沟通和安全意识问题, 所以重点在于把敏感操作转移到一个可靠且有判断能力的人手里 (一般就是老人自己的子女), 而且不能让老人知悉真正的登录信息以及支付密码。

我有一个方案是为了代理 oauth2.0 登录流程 (主要是 keycloak) 做的, 感觉可以迁移到这种应用场景, 个人感觉不适合在公共频道讨论, 三位要是有兴趣讨论的话欢迎与我邮件交流

aW5xdWlyaWVzQGFyaGF0LnNvbHV0aW9ucw==

(同时为了安全需要, 需要在邮件中提供能 V2EX 用户名以及能与 V2EX 用户交叉认证第三方平台链接)

有同样的需求，我的解决方案是把单个 secret item 通过 fuse 挂载成一个独立文件，应用程序读取文件会触发授权请求，请求带有 uid, pid, 进程名以及进程调用链等，通过自定义 webhook 服务进行授权，成功授权才能读取文件内容。

@jeffreystoke 补充一下，这个办法并不可靠，ref 里面也提到了部分实现没有遵循这个标准，因为 ietf 虽然在 RFC 里面写了这个标准，但是又不推荐服务端这么实现，所以现实情况就是用 tls 1.3 基本不可能获得服务器时间，tls 1.2 有一定可能性，tls1.1 可能性极高，老旧的 ssl 应该完全可行。

Ref: https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/

如果服务器有 tls 服务的话可以通过 tls handshake 过程中的 srverhello 消息推断，random string 的前四个字节是 unix timestamp 。

Ref: https://security.stackexchange.com/questions/71364/tls-reliance-on-system-time#71368

@gjquoiai 感谢推荐，正是我想要的，和这个软件可以配合

我现在是用 git-secret 加密 helm values 文件，用 credentialfs 保存 git-secret 的 seed，大量私密且需要频繁改动的文件这样操作似乎更方便一点