部署Django项目后授予客户服务器权限，如何保护源代码不泄露？

给客户开放服务器访问权限还想保住源代码？这几个方案能帮你降低泄露风险：

1. 代码、数据库彻底隔离 #

• 把数据库单独部署在另一台服务器或者私有子网里，只让Django应用服务器能通过内部网络访问数据库端口（比如PostgreSQL的5432），绝对不让客户碰数据库服务器的权限。
• 对外只开放应用的服务端口（80/443），客户只能使用你的应用，连代码部署的服务器都只能拥有受限访问权限，更别说直接接触数据库了。

2. 只部署编译后的字节码 #

• Python代码可以编译成.pyc字节码文件，用python -m compileall .命令批量编译整个项目，之后删掉原始的.py文件，只把编译后的文件上传到服务器。
• 虽然字节码存在被反编译的可能，但比起明文源码，破解门槛高太多，普通客户很难拿到可读的代码内容。

3. Docker容器锁死权限 #

• 容器内部用非root用户运行Django，不要给容器挂载宿主机的敏感目录，也禁止容器获取宿主机的文件读写权限。
• 不给客户导出镜像的权限，启动容器时直接运行Django的WSGI服务器（比如gunicorn myproject.wsgi），避免客户能进入容器shell。
• 还可以添加--read-only参数把容器文件系统设为只读，只把日志、静态文件这类必须写入的目录单独挂载为可写，彻底限制容器内的修改操作。

4. 服务器权限砍到最小 #

• 给客户的账号只开放应用部署目录的只读权限，甚至通过sudoers或者ACL规则，禁止他们使用cat、less这类能查看文件内容的命令。
• 不让客户使用docker exec进入容器排查问题，要查看运行状态就给他们开放日志查看权限（比如docker logs），或者搭建简单的监控面板，绝对不能提供直接的服务器shell权限。

5. 核心代码加密混淆 #

• 用pyarmor这类工具给核心业务代码加密，生成只能在授权环境运行的加密字节码，就算客户拿到文件也反编译不出可读代码。
• 配置文件里的数据库密码、SECRET_KEY这些敏感信息单独加密存储，运行时通过脚本动态解密加载，不要明文写在代码里。

内容的提问来源于stack exchange，提问作者Mohawo