Linux
如何管理以非 root 使用者執行的容器的綁定掛載所有權和權限?
我們在 RHEL 主機上使用 Red Hat 容器鏡像,全部基於它們的 ubi7 或 ubi8 鏡像,預設情況下,它們以預設使用者 (uid 1001) 執行。
這在容器需要對主機目錄進行寫訪問(即寫入日誌或臨時文件)時提出了挑戰,因為主機的 UID 和 GID 保存在容器中,而容器寫入的文件將歸該 UID 所有容器使用者。
據我所知,這給我留下了兩個選擇:
- 在我的主機上創建一個 UID 為 1001 的使用者,並將該使用者設置為已安裝卷的所有者。這可能會帶來問題,因為 UID 1001 是在不強制使用特定 UID 的主機上添加新使用者時將使用的第一個 UID。因此,如果需要將容器部署在可能具有或不具有相同一致 UID 映射的多台伺服器上,則可能很難管理。然而,據我所知,這將是唯一的方法,容器寫入的文件的所有者(UID 1001)與主機上的所需使用者匹配,並且主機上寫入的文件的所有者與現有的 UID 匹配容器。
- 將掛載的主機目錄設為全域可寫,這會帶來許多安全隱患,其中之一是主機上的任何使用者都有權刪除容器寫入的文件。如果 UID 1001 已分配給主機上的另一個使用者,這些文件也可能顯示為由另一個使用者擁有。
通常,我會在容器鏡像中創建一個匹配的 user:group 組合,在需要的地方重置所有權和權限並重建它,但是對於 Red Hat 創建的鏡像,這意味著很多工作要做,因為一切都是為了使用 UID 1001 執行,並且有許多腳本(容器入口點修復權限、生成容器使用者)以這種方式強制它。
我是否正確理解了所有內容,還是有另一種(更好的)方法可以做到這一點?
我只是想通了… Red Hat 映像會自動將預設使用者的 uid 更改為您使用 generate-container-user 腳本執行容器的任何內容,因此我只需要使用 USER 完成我的 Dockerfile 或執行它與 –user 一起工作。
還有另一種方法嗎?
另一種選擇是使用 ACL。ACL 可以比使用者/組/其他標準 *nix 權限靈活得多。
當然,ACL 的靈活性也使它們變得更加複雜。您可以使用類似下面的範例來設置 ACL。
花一些時間閱讀 acl、setfacl、getfacl 的手冊頁並進行一些測試以確保您獲得正確的權限。ACL 很複雜,下面只是一個範例。
- https://linux.die.net/man/5/acl
- https://linux.die.net/man/1/setfacl
- https://linux.die.net/man/1/getfacl
例子
set_acl 腳本
TMP_DIR_ACL=path/acl_directories FILE_ACL=path/acl_files ITEMPATH=/srv/data OWNER=root GROUP=root # set user/group owner on any existing files/dirs find $ITEMPATH ! -user $OWNER -exec chown --no-dereference $OWNER {} + find $ITEMPATH ! -group $GROUP -exec chgrp --no-dereference $GROUP {} + # set acls for all existing direcoties find $ITEMPATH -type d -exec setfacl --modify-file $DIR_ACL $ITEMPATH {} + # set acls for all existing files find $ITEMPATH -type f -exec setfacl --modify-file $FILE_ACL $ITEMPATH {} + # makes any files created in a directory be owned by the directories group find $ITEMPATH -type d -exec chmod g+s {} +
acl_directories
group::r-x mask::rwx other::r-x user::rwx user:1001:rwx default:group::rwx default:mask::rwx default:other::r-x default:user::rwx default:user:1001:rwx
acl_files
user::rwX user:1001:rwX group::r-X other::r-X