问题描述
在交付应用程序时，你希望将其以Docker镜像的形式提供给客户。但是，确保终端用户无法更改容器内部的任何内容至关重要。用户只能运行/停止容器，并可以通过网络与容器进行交互。你想知道是否有办法禁止访问容器的内部。你还想了解是否有可能验证从镜像创建的容器的完整性。
解决方案
请注意以下操作可能会涉及版本差异或特定环境的设置。在执行任何更改之前，请确保备份相关数据和配置。
方案1：提供操作工具并制定授权协议
如果你提供用于操作所提供容器的工具（如监视和日志记录工具），可以在软件许可协议中要求客户同意不对其进行未经授权的修改。这种方法适用于各种第三方软件，而不仅仅是容器。
方案2：SaaS模式运行应用程序
如果客户要求在其基础设施上运行你的容器，但拒绝遵守修改限制，那么你可能不希望尝试支持他们对你的软件的使用。在这种情况下，你可以考虑将你的应用程序作为一项基于云基础设施的软件即服务（SaaS）提供。
方案3：图像代码混淆和基础镜像选择
虽然Docker本身不能阻止用户访问容器，但作为镜像开发者，你可以采取一些策略来增加访问控制和安全性：
– 对你的应用程序代码进行混淆，以减少代码可读性，从而降低用户进行修改的难度。
– 使用不包含Shell和其他用户可用于篡改镜像的二进制文件的基础镜像进行构建。这可以减少用户操纵镜像的能力。
当然，用户仍然可以将容器导出并重新打包，但这需要一些极端措施。
方案4：Docker企业版（EE）的使用
如果客户愿意投资，你可以考虑使用Docker企业版（EE）。在Docker EE中，你可以使用“UCP（Universal Control Plane）”来创建角色和访问权限，从而限制用户更改/修改容器的能力。使用UCP可以对容器进行更精细的访问控制。
方案5：自定义启动脚本
你可以编写自定义启动脚本，以确保容器在运行之前执行特定的检查，从而增加容器的完整性验证。例如，你可以在启动容器之前验证镜像的哈希值，并拒绝启动不完整或已修改的容器。
总结
虽然Docker本身不能完全阻止用户访问容器内部，但通过结合多种策略，如授权协议、基础镜像选择、自定义脚本等，你可以增加容器的完整性验证和访问控制。根据你的实际需求和客户要求，选择适合的方案以达到预期的安全性和控制级别。
请注意，在执行任何更改之前，请详细阅读相关文档，并在安全环境中进行测试。
希望以上解决方案对于你的需求有所帮助。如果你有任何进一步的问题或疑虑，请随时提问。