@dgoodwin

@coeki Saya tidak berpikir kami secara teknis mendokumentasikan instalasi Fedora, saya berasumsi Anda menggunakan repo Centos7? Docker mana yang Anda gunakan, yang ada di Fedora atau yang dari Docker Inc? Bisakah Anda memasukkan detail tentang penolakan?

spc_t harus benar per http://danwalsh.livejournal.com/2016/10/03/

@jasonbrooks apakah Anda memiliki pemikiran tentang ini, potensi dampak dari https://github.com/kubernetes/kubernetes/pull/37327

Saya akan mencoba mencari waktu untuk melihat apakah saya dapat mereproduksi minggu ini.

Direproduksi:

type=AVC msg=audit(1484057408.459:2715): avc:  denied  { entrypoint } for  pid=16812 comm="exe" path="/usr/local/bin/etcd" dev="dm-6" ino=4194436 scontext=system_u:system_r:spc_t:s0:c133,c303 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c133,c303 tclass=file permissive=0

Tidak terjadi pada CentOS 7 sejauh yang saya tahu.

Hai,

Ya, itulah jenis kesalahan yang saya lihat. Untuk klarifikasi, ya saya menggunakan repo Centos dan saya menggunakan buruh pelabuhan dari repo Fedoras.

Saya akan melakukan pemeriksaan cepat jika ini terjadi dengan Centos7 hari ini.

Terima kasih,

Hai,

Sebenarnya terjadi pada centos7 juga:

type=AVC msg=audit(1484065309.021:634): avc: ditolak { entrypoint } untuk pid=12204 comm="exe" path="/usr/local/bin/etcd" dev="dm-9" ino=4194436 scontext =system_u:system_r:spc_t:s0:c390,c679 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c390,c679 tclass=file
type=AVC msg=audit(1484065310.113:637): avc: ditolak { entrypoint } untuk pid=12263 comm="exe" path="/usr/local/bin/etcd" dev="dm-9" ino=4194436 scontext =system_u:system_r:spc_t:s0:c220,c274 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c220,c274 tclass=file
type=AVC msg=audit(1484065323.851:661): avc: ditolak { entrypoint } untuk pid=12550 comm="exe" path="/usr/local/bin/etcd" dev="dm-9" ino=4194436 scontext =system_u:system_r:spc_t:s0:c425,c863 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c425,c863 tclass=file

Mengenai posting Dan Walsh, saya juga melihat ini http://danwalsh.livejournal.com/75011.html , jadi saya pikir semuanya berubah.

Hal-hal lain yang saya lihat:

[ root@localhost gelandangan]# ls -Z /var/lib/ |grep container
drwx-----x. root root system_u:object_r:container_var_lib_t:s0 buruh pelabuhan
drwxr-xr-x. root root system_u:object_r:container_var_lib_t:s0 dll
[ root@localhost gelandangan]# ls -Z /var/lib/ |grep kubelet
drwxr-x---. root root system_u:object_r:var_lib_t:s0 kubelet

[ root@localhost gelandangan]# ls -Z /var/lib/kubelet/pods/3a26566bb004c61cd05382212e3f978f/containers/etcd/
-rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c425,c863 00cb813c
-rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c220,c274 066b8a86
-rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c390,c679 0c8e84af
-rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c12,c477 342bd480
-rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c215,c768 995f6946
-rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c23,c405 e184aa90
-rw-r--r--. root root system_u:object_r:svirt_sandbox_file_t:s0:c65,c469 eb05320c

Hal yang sama pada Centos dan Fedora. Tidak yakin apa jalannya, tetapi saya pikir kita tidak perlu menentukan tipe SElinux lagi dalam manifes apa pun. Setidaknya untuk kubeadm, jaringan pod adalah cerita lain.

Pikiran?

Terima kasih,

Aku sedang menyodok ini sekarang.

Terima kasih @jasonbrooks.

FWIW CentOS7 bersih untuk saya dengan:

(root<strong i="8">@centos1</strong> ~) $ kubeadm reset
[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
[reset] No etcd manifest found in "/etc/kubernetes/manifests/etcd.json", assuming external etcd.
[reset] Deleting contents of stateful directories: [/var/lib/kubelet /etc/cni/net.d]
[reset] Deleting contents of config directories: [/etc/kubernetes/manifests /etc/kubernetes/pki]
[reset] Deleting files: [/etc/kubernetes/admin.conf /etc/kubernetes/kubelet.conf]
(root<strong i="9">@centos1</strong> ~) $ getenforce
Enforcing
(root<strong i="10">@centos1</strong> ~) $ rpm -qa | grep kube
kubelet-1.5.1-0.x86_64
kubeadm-1.6.0-0.alpha.0.2074.a092d8e0f95f52.x86_64
kubectl-1.5.1-0.x86_64
kubernetes-cni-0.3.0.1-0.07a8a2.x86_64
(root<strong i="11">@centos1</strong> ~) $ ls -lZ /var/lib | grep docker
drwx-----x. root    root    system_u:object_r:docker_var_lib_t:s0 docker/
drwxr-xr-x. root    root    system_u:object_r:docker_var_lib_t:s0 etcd/
drwxr-xr-x. root    root    system_u:object_r:docker_var_lib_t:s0 kubeadm-etcd/
(root<strong i="12">@centos1</strong> ~) $ rpm -qa | grep selinux
selinux-policy-targeted-3.13.1-60.el7_2.3.noarch
libselinux-2.2.2-6.el7.x86_64
docker-selinux-1.10.3-46.el7.centos.10.x86_64
libselinux-utils-2.2.2-6.el7.x86_64
libselinux-python-2.2.2-6.el7.x86_64
selinux-policy-3.13.1-60.el7_2.3.noarch

kubeadm init berfungsi dan ini adalah env yang saya lakukan pengujian untuk memverifikasi semuanya baik-baik saja.

Saya kemudian berpikir untuk memeriksa apakah mesin gelandangan saya menjalankan kebijakan terbaru dan mengambil banyak pembaruan selinux, setelah itu kubeadm init sekarang gagal dengan penolakan yang diberikan oleh @coeki. Jadi ada yang salah dengan kebijakan terbaru. Setelah pembaruan saya:

(root<strong i="17">@centos1</strong> ~) $ rpm -qa | grep selinux
libselinux-2.5-6.el7.x86_64
docker-selinux-1.10.3-46.el7.centos.14.x86_64
selinux-policy-targeted-3.13.1-102.el7_3.7.noarch
libselinux-python-2.5-6.el7.x86_64
selinux-policy-3.13.1-102.el7_3.7.noarch
libselinux-utils-2.5-6.el7.x86_64
container-selinux-1.10.3-59.el7.centos.x86_64

Lihat ini. CentOS 7 dengan docker-selinux:

$ sesearch -T -s docker_t | grep spc_t
   type_transition docker_t docker_share_t : process spc_t; 
   type_transition docker_t unlabeled_t : process spc_t; 
   type_transition docker_t docker_var_lib_t : process spc_t;

Dan setelah menginstal container-selinux:

$ sesearch -T -s docker_t | grep spc_t
   type_transition container_runtime_t container_var_lib_t : process spc_t; 
   type_transition container_runtime_t container_share_t : process spc_t;

Ya, saya menambahkan exclude=container-selinux ke fedora-updates repo saya dan kubeadm init selesai seperti yang diharapkan.

ping @rhatdan

Jadi kita harus mendokumentasikan exclude=container-selinux sebagai solusi untuk mengaktifkan SELinux ( setenforce 1 ) dan menjalankan kubeadm?

Saya pikir kita memerlukan perbaikan selinux untuk mengatasi ini.

Pada 10 Januari 2017 22:41, "Lucas Käldström" [email protected] menulis:

Jadi kita harus mendokumentasikan pengecualian=container-selinux sebagai solusi untuk memiliki
SELinux aktif (setenforce 1) dan menjalankan kubeadm?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubeadm/issues/107#issuecomment-271791032 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAG52vBqKyMAcSj62oGqazI2hWETd-RPks5rRHmZgaJpZM4Le4yP
.

Setelah membaca posting yang disebutkan dari Dan Walsh ( http://danwalsh.livejournal.com/75011.html ) sedikit lebih baik, entah ada kesalahan dalam mengetik tipe docker_t ke nama generik baru untuk tipe kontainer container_t, atau tidak ditarik belum.

Kereta pemikiran lain. Saya tidak yakin bagaimana wadah buruh pelabuhan diluncurkan oleh kubernetes, tetapi perbaikan juga bisa dilakukan dengan meluncurkan wadah dengan tipe wadah baru.

Abaikan komentar terakhir, tentu saja itu runtime penampung OS, jadi ya komentar @jasonbrooks benar, kita perlu perbaikan selinux.

@lsm5 bisakah kita mendapatkan versi terbaru dari container-selinux untuk Fedora 24. Tampaknya agak ketinggalan zaman di sana.

@rhatdan @lsm5 juga buruk di CentOS 7 terbaru

Versi docker, docker-selinux, container-selinux apa yang dimiliki Centos 7?

Dari atas:

(root<strong i="6">@centos1</strong> ~) $ rpm -qa | grep selinux
libselinux-2.5-6.el7.x86_64
docker-selinux-1.10.3-46.el7.centos.14.x86_64
selinux-policy-targeted-3.13.1-102.el7_3.7.noarch
libselinux-python-2.5-6.el7.x86_64
selinux-policy-3.13.1-102.el7_3.7.noarch
libselinux-utils-2.5-6.el7.x86_64
container-selinux-1.10.3-59.el7.centos.x86_64

Dalam komentar saya di atas, Anda juga dapat melihat versi sebelumnya yang saya miliki di mana semuanya berfungsi, dan kemudian mulai gagal setelah pembaruan yum ke versi ini.

@dgoodwin dapatkah Anda mencoba container-selinux terbaru untuk CentOS 7? Anda bisa mendapatkannya menggunakan repo ini:

[virt7-docker-common-candidate]
name=virt7-docker-common-candidate
baseurl=https://cbs.centos.org/repos/virt7-docker-common-candidate/x86_64/os/
enabled=1
gpgcheck=0

Lihat: https://wiki.centos.org/Cloud/Docker

Khususnya, http://cbs.centos.org/koji/buildinfo?buildID=15216

Masih gagal @lsm5

(root<strong i="7">@centos1</strong> ~) $ rpm -qa | grep selinux                                                                                                     
libselinux-2.5-6.el7.x86_64
selinux-policy-targeted-3.13.1-102.el7_3.7.noarch
libselinux-python-2.5-6.el7.x86_64
selinux-policy-3.13.1-102.el7_3.7.noarch
container-selinux-2.2-3.el7.noarch
libselinux-utils-2.5-6.el7.x86_64

type=AVC msg=audit(1484146410.625:156): avc:  denied  { entrypoint } for  pid=2831 comm="exe" path="/usr/local/bin/etcd" dev="dm-8" ino=8388868 scontext=system_u:system_r:spc_t:s0:c590,c748 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c590,c748 tclass=file
type=AVC msg=audit(1484146437.147:168): avc:  denied  { entrypoint } for  pid=3102 comm="exe" path="/usr/local/bin/etcd" dev="dm-9" ino=8388868 scontext=system_u:system_r:spc_t:s0:c73,c888 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c73,c888 tclass=file
type=AVC msg=audit(1484146454.690:174): avc:  denied  { entrypoint } for  pid=3269 comm="exe" path="/usr/local/bin/etcd" dev="dm-9" ino=8388868 scontext=system_u:system_r:spc_t:s0:c184,c206 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c184,c206 tclass=file
type=AVC msg=audit(1484146479.755:179): avc:  denied  { entrypoint } for  pid=3375 comm="exe" path="/usr/local/bin/etcd" dev="dm-9" ino=8388868 scontext=system_u:system_r:spc_t:s0:c245,c784 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c245,c784 tclass=file
type=AVC msg=audit(1484146529.400:190): avc:  denied  { entrypoint } for  pid=3637 comm="exe" path="/usr/local/bin/etcd" dev="dm-9" ino=8388868 scontext=system_u:system_r:spc_t:s0:c893,c1013 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c893,c1013 tclass=file

Bisakah Anda memastikan container-selinux berhasil diinstal?

dnf instal ulang container-selinux

Saya mencoba dengan container-selinux versi terbaru kemarin di CentOS
dan saya juga mencoba container-selinux yang ada di update-testing untuk f25,
masalah yang sama.

Pada 11 Januari 2017 07:32, "Daniel J Walsh" [email protected] menulis:

Bisakah Anda memastikan container-selinux berhasil diinstal?

dnf instal ulang container-selinux

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubeadm/issues/107#issuecomment-271899571 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAG52tRhNh6En1hfbZJzzGISzNUnhVfKks5rRPYUgaJpZM4Le4yP
.

Saya pikir blok ini gagal secara diam-diam.

opsional_kebijakan(`
virt_stub_svirt_sandbox_file()
virt_transition_svirt_sandbox(spc_t, system_r)
virt_sandbox_entrypoint(spc_t)
virt_sandbox_domtrans(container_runtime_t, spc_t)
')

Masih gagal setelah menginstal ulang.

Saya sedang menyiapkan mesin CENTOS untuk memeriksa apa yang salah.

Terima kasih atas bantuan semuanya, akan sangat keren jika kita dapat membuat setenforce 1 bekerja dengan kubeadm di rilis berikutnya ;)

Hai,

Saya mencoba dengan fedora 25 cloud base, hasil yang sama seperti di, tidak menginstal, tetapi pesan yang berbeda:

waktu->Sab 21 Jan 13:55:37 2017

type=AVC msg=audit(1485006937.554:8062): avc: ditolak { buat } untuk pid=676 comm="etcd" name="data" scontext=system_u:system_r:container_t:s0:c358,c612 tcontext=system_u:object_r :container_var_lib_t:s0 tclass=dir permissive=0

waktu->Sab 21 Jan 13:57:08 2017

type=AVC msg=audit(1485007028.572:8075): avc: ditolak { buat } untuk pid=1181 comm="etcd" name="data" scontext=system_u:system_r:container_t:s0:c358,c612 tcontext=system_u:object_r :container_var_lib_t:s0 tclass=dir permissive=0

waktu->Sab 21 Jan 13:59:53 2017
type=AVC msg=audit(1485007193.515:8088): avc: ditolak { buat } untuk pid=1780 comm="etcd" name="data" scontext=system_u:system_r:container_t:s0:c358,c612 tcontext=system_u:object_r :container_var_lib_t:s0 tclass=dir permissive=0

[ root@master-01 gelandangan]# rpm -qa |grep selinux
libselinux-python3-2.5-13.fc25.x86_64
selinux-policy-3.13.1-225.6.fc25.noarch
libselinux-2.5-13.fc25.x86_64
libselinux-utils-2.5-13.fc25.x86_64
rpm-plugin-selinux-4.13.0-6.fc25.x86_64
selinux-policy-targeted-3.13.1-225.6.fc25.noarch
libselinux-python-2.5-13.fc25.x86_64
container-selinux-2.2-2.fc25.noarch

Ups, maaf untuk markup di posting terakhir, tidak tahu bagaimana itu terjadi;)

@coeki itu karena # di awal baris itu. Saya menyarankan indentasi baris dengan empat spasi, yang memungkinkan GH tahu bahwa itu kode.

@jberkus terima kasih, saya akan mengingatnya.

Saya akan mencoba atom fedora, yang merupakan permainan bola baru bagi saya. Tetapi karena @rhatdan mengatakan itu berfungsi di bawah itu, saya penasaran. Saya akan melaporkan temuan saya, jika saya berhasil;)

Itu menunjukkan bahwa Anda memasang volume di direktori dari Host ke wadah buruh pelabuhan, tanpa memberi label ulang. Saya pikir ini adalah masalah yang diketahui di k8s dan seharusnya diperbaiki di versi yang lebih baru.

Saya baru saja menguji ini dengan f25 dan panduan kubeadm dari sini . Terjebak di [apiclient] Created API client, waiting for the control plane to become ready

[root@fedora-1 ~]# rpm -q docker container-selinux kubelet kubeadm
docker-1.12.6-5.git037a2f5.fc25.x86_64
container-selinux-2.2-2.fc25.noarch
kubelet-1.5.1-0.x86_64
kubeadm-1.6.0-0.alpha.0.2074.a092d8e0f95f52.x86_64
[root@fedora-1 ~]# ausearch -m avc -ts recent
----
time->Wed Jan 25 18:47:12 2017
type=AVC msg=audit(1485388032.826:415): avc:  denied  { create } for  pid=9080 comm="etcd" name="data" scontext=system_u:system_r:container_t:s0:c159,c642 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=dir permissive=0
----
time->Wed Jan 25 18:52:43 2017
type=AVC msg=audit(1485388363.049:459): avc:  denied  { create } for  pid=9940 comm="etcd" name="data" scontext=system_u:system_r:container_t:s0:c159,c642 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=dir permissive=0

Saya memiliki versi modifikasi tweak untuk bekerja dengan atom dalam copr , yang mencakup v.1.5.2, tapi itu juga terpengaruh.

Jika saya kembali ke versi docker terakhir untuk fedora sebelum transisi docker-selinux ke container-selinux, kubeadm berfungsi dengan baik dengan penegakan selinux:

# rpm -q docker docker-selinux
docker-1.12.1-13.git9a3752d.fc25.x86_64
docker-selinux-1.12.1-13.git9a3752d.fc25.x86_64

Coba instal container-selinux dari pengujian pembaruan, meskipun saya masih berpikir masalahnya di sini adalah dengan kubernetes yang menangani pelabelan.

Ini dengan container-selinux-2.4-1.fc25.noarch :

time->Thu Jan 26 02:49:26 2017
type=AVC msg=audit(1485416966.739:468): avc:  denied  { create } for  pid=9778 comm="etcd" name="data" scontext=system_u:system_r:container_t:s0:c213,c267 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=dir permissive=0
----
time->Thu Jan 26 02:50:13 2017
type=AVC msg=audit(1485417013.023:512): avc:  denied  { create } for  pid=11274 comm="etcd" name="data" scontext=system_u:system_r:container_t:s0:c164,c200 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=dir permissive=1
----
time->Thu Jan 26 02:50:13 2017
type=AVC msg=audit(1485417013.023:513): avc:  denied  { create } for  pid=11274 comm="etcd" name=".touch" scontext=system_u:system_r:container_t:s0:c164,c200 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=1
----
time->Thu Jan 26 02:50:13 2017
type=AVC msg=audit(1485417013.023:514): avc:  denied  { write open } for  pid=11274 comm="etcd" path="/var/etcd/data/.touch" dev="dm-0" ino=33776166 scontext=system_u:system_r:container_t:s0:c164,c200 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=1
----
time->Thu Jan 26 02:50:13 2017
type=AVC msg=audit(1485417013.023:515): avc:  denied  { unlink } for  pid=11274 comm="etcd" name=".touch" dev="dm-0" ino=33776166 scontext=system_u:system_r:container_t:s0:c164,c200 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=1
----
time->Thu Jan 26 02:50:13 2017
type=AVC msg=audit(1485417013.023:516): avc:  denied  { read } for  pid=11274 comm="etcd" path="/var/etcd/data/member/snap/db" dev="dm-0" ino=498029 scontext=system_u:system_r:container_t:s0:c164,c200 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=1
----
time->Thu Jan 26 02:50:13 2017
type=AVC msg=audit(1485417013.023:517): avc:  denied  { lock } for  pid=11274 comm="etcd" path="/var/etcd/data/member/snap/db" dev="dm-0" ino=498029 scontext=system_u:system_r:container_t:s0:c164,c200 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=1
----
time->Thu Jan 26 02:50:13 2017
type=AVC msg=audit(1485417013.041:518): avc:  denied  { rename } for  pid=11274 comm="etcd" name="wal.tmp" dev="dm-0" ino=17291587 scontext=system_u:system_r:container_t:s0:c164,c200 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=dir permissive=1

Apa yang saya tidak mengerti adalah bagaimana versi kubernetes yang sama yang tidak berfungsi dengan container-selinux saat ini atau pengujian berfungsi dengan baik dengan docker dan docker-selinux yang lebih lama. Apakah container_t mengizinkan semua yang diizinkan oleh spc_t?

@jasonbrooks jika Anda buruh pelabuhan ps -a, temukan wadah etcd yang gagal, dan buruh pelabuhan memeriksanya apa yang Anda lihat untuk opsi keamanan?

Jika itu seperti ini:

  "SecurityOpt": [
                "seccomp=unconfined",
                "label:type:spc_t",
                "label=user:system_u",
                "label=role:system_r",
                "label=type:svirt_lxc_net_t",
                "label=level:s0:c803,c806"
            ],

Anda mungkin mengalami masalah terpisah yang muncul dengan Docker 1.12+, yang sedang dikerjakan pmorie di sini: https://github.com/kubernetes/kubernetes/pull/40179

@dgoodwin Saya baru saja melakukan instalasi baru di fedora 25, dan dapat mengonfirmasi semua yang dilihat @jasonbrooks .

keluaran buruh pelabuhan memeriksa wadah etcd:

"SecurityOpt": [
            "seccomp=unconfined",
            "label:type:spc_t",
            "label=user:system_u",
            "label=role:system_r",
            "label=type:container_t",
            "label=level:s0:c122,c403"
        ],

rpm -q wadah-selinux:

container-selinux-2.2-2.fc25.noarch

Oke itu https://github.com/kubernetes/kubernetes/issues/37807 dan https://github.com/kubernetes/kubernetes/pull/40179.

Sedikit lebih banyak info. Saat menggunakan docker-1.12.1-13.git9a3752d.fc25.x86_64 dan docker-selinux (yaitu docker api v1.24), berikut adalah opsi keamanan kontainer etcd:

"SecurityOpt": [
                "seccomp=unconfined",
                "label:type:spc_t"
            ],

Dengan docker-1.12.6-5.git037a2f5.fc25.x86_64 (juga docker api v1.24) dan container-selinux, opsi keamanannya adalah:

"SecurityOpt": [
                "seccomp=unconfined",
                "label:type:spc_t",
                "label=user:system_u",
                "label=role:system_r",
                "label=type:container_t",
                "label=level:s0:c306,c898"
            ],

Transisi kembali ke masalah ini karena saya yakin kami masih memiliki masalah container-selinux dengan Docker 1.12.

Jika Anda menerapkan perbaikan dari https://github.com/kubernetes/kubernetes/issues/37807 ini akan memperbaiki masalah pemisah label di atas sehingga semua label muncul dengan =. Namun, masalahnya tetap ada, container_t terus ditambahkan setelah spc_t dan pod akan ditolak.

Reproduksi paling sederhana yang dapat saya temukan hanyalah cluster hack lokal dan membuat manifes di bawah ini:

Fedora 25, kubernetes berkembang dengan paket-paket berikut:

docker-1.12.6-5.git037a2f5.fc25.x86_64
container-selinux-2.4-1.fc25.noarch

$ sudo ALLOW_SECURITY_CONTEXT=1 PATH=$PATH:/home/dgoodwin/go/src/k8s.io/kubernetes/third_party/etcd:/home/dgoodwin/go/bin hack/local-up-cluster.sh

in another terminal:

$ kubectl --kubeconfig /var/run/kubernetes/admin.kubeconfig create -f https://gist.githubusercontent.com/dgoodwin/1c19d2ad184ff792f786fec3cd137d0b/raw/beaaaa466b1073cacf4ec92f8ade9da28ad3233e/etcd.json



md5-4ae8d3f78540a9a1aead6709cda723e4



type=AVC msg=audit(1485449563.680:10995): avc:  denied  { create } for  pid=17157 comm="etcd" name=".touch" scontext=system_u:system_r:container_t:s0:c632,c788 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=0



md5-cefed6e5c6deb76a7e4f6a58d8b17b81



            "SecurityOpt": [
                "seccomp=unconfined",
                "label=type:spc_t",
                "label=user:system_u",
                "label=role:system_r",
                "label=type:container_t",
                "label=level:s0:c632,c788"
            ],

container_t menggantikan spc_t yang kami minta dalam manifes seperti yang Anda lihat di sini: https://Gist.githubusercontent.com/dgoodwin/1c19d2ad184ff792f786fec3cd137d0b/raw/beaaaa466b1073cacf4ec92f8ade9da28ad3233e/etcd.json

CC @pweil @eparis @pmorie @rhatdan

container-selinux tidak ada hubungannya dengan ini. Sepertinya itu pasti masalah buruh pelabuhan. Anda harus dapat menginstal versi buruh pelabuhan yang lebih lama dengan container-selinux dan saya berani bertaruh perilaku lama akan kembali.

Tampaknya berfungsi dengan baik dari klien.

docker run -d --security-opt label= type:spc_t fedora sleep 50

            "SecurityOpt": [
                "label=type:spc_t"
            ],

Tapi ini menunjukkan bug yang serupa, tetapi tidak semua konten lainnya

docker run -ti --security-opt label= type:spc_t --security-opt label= type:container_t fedora sleep 50

            "SecurityOpt": [
                "label=type:spc_t",
                "label=type:container_t"
            ],

@rhatdan @mrunalp dengan reproduksi @dgoodwin Saya dapat menemukan apa yang menyebabkan ini untuk projectatomic/docker dengan 1.12.6 - yang merupakan tambalan ini https://github.com/projectatomic/docker/commit/07f6dff6273f98a2da8731b87f8dd98d86a5d6ff

Mengembalikan itu tampaknya memperbaiki masalah ini. Namun patch itu tampaknya diperlukan dan docker upstream memiliki patch itu di rilis docker 1.13.0 terbaru mereka (jadi upstream memiliki masalah yang sama di 1.13 tetapi tidak di upstream 1.12.6).

@rhatdan apa hal yang diharapkan yang masuk ke SecurityOpt jika Anda menentukan lebih dari satu label dengan flag security-opt saat docker run?

docker run -ti --security-opt label= type:spc_t --security-opt label= type:container_t fedora sleep 50

apakah Anda ingin memilih keamanan hanya container_t atau spc_t? Maksudku, itu harus satu atau yang lain kan? keduanya tidak bisa hidup berdampingan kan?

Saya tidak yakin apakah ini masalah buruh pelabuhan atau masalah kubernetes dari membaca tambalan di atas, sepertinya wadah jeda berjalan di bawah kurungan, dan kami menggabungkan proses wadah ke wadah yang sedang berjalan?

Masalahnya tampaknya sederhana, inilah konfigurasi yang digunakan untuk membuat jeda dan wadah etcd (dengan wadah etcd bergabung dengan namespace ipc dari wadah jeda):

Jan 28 12:55:23 runcom.usersys.redhat.com dockerd-current[4199]: time="2017-01-28T12:55:23.362797988+01:00" level=debug msg="form data: {\"AttachStderr\":false,\"AttachStdin\":false,\"AttachStdout\":false,\"Cmd\":null,\"Domainname\":\"\",\"Entrypoint\":null,\"Env\":[\"KUBERNETES_PORT=tcp://10.0.0.1:443\",\"KUBERNETES_PORT_443_TCP=tcp://10.0.0.1:443\",\"KUBERNETES_PORT_443_TCP_PROTO=tcp\",\"KUBERNETES_PORT_443_TCP_PORT=443\",\"KUBERNETES_PORT_443_TCP_ADDR=10.0.0.1\",\"KUBERNETES_SERVICE_HOST=10.0.0.1\",\"KUBERNETES_SERVICE_PORT=443\",\"KUBERNETES_SERVICE_PORT_HTTPS=443\"],\"HostConfig\":{\"AutoRemove\":false,\"Binds\":null,\"BlkioDeviceReadBps\":null,\"BlkioDeviceReadIOps\":null,\"BlkioDeviceWriteBps\":null,\"BlkioDeviceWriteIOps\":null,\"BlkioWeight\":0,\"BlkioWeightDevice\":null,\"CapAdd\":null,\"CapDrop\":null,\"Cgroup\":\"\",\"CgroupParent\":\"\",\"ConsoleSize\":[0,0],\"ContainerIDFile\":\"\",\"CpuCount\":0,\"CpuPercent\":0,\"CpuPeriod\":0,\"CpuQuota\":0,\"CpuShares\":2,\"CpusetCpus\":\"\",\"CpusetMems\":\"\",\"Devices\":[],\"DiskQuota\":0,\"Dns\":[\"8.8.8.8\"],\"DnsOptions\":null,\"DnsSearch\":[\"vutbr.cz\",\"usersys.redhat.com\"],\"ExtraHosts\":null,\"GroupAdd\":null,\"IOMaximumBandwidth\":0,\"IOMaximumIOps\":0,\"IpcMode\":\"\",\"Isolation\":\"\",\"KernelMemory\":0,\"Links\":null,\"LogConfig\":{\"Config\":null,\"Type\":\"\"},\"Memory\":0,\"MemoryReservation\":0,\"MemorySwap\":-1,\"MemorySwappiness\":null,\"NetworkMaximumBandwidth\":0,\"NetworkMode\":\"\",\"OomKillDisable\":null,\"OomScoreAdj\":-998,\"PidMode\":\"\",\"PidsLimit\":0,\"PortBindings\":{},\"Privileged\":false,\"PublishAllPorts\":false,\"ReadonlyRootfs\":false,\"RestartPolicy\":{\"MaximumRetryCount\":0,\"Name\":\"\"},\"SecurityOpt\":[\"seccomp=unconfined\"],\"ShmSize\":6.7108864e+07,\"StorageOpt\":null,\"UTSMode\":\"\",\"Ulimits\":null,\"UsernsMode\":\"\",\"VolumeDriver\":\"\",\"VolumesFrom\":null},\"Hostname\":\"etcd\",\"Image\":\"gcr.io/google_containers/pause-amd64<strong i="6">@sha256</strong>:163ac025575b775d1c0f9bf0bdd0f086883171eb475b5068e7defa4ca9e76516\",\"Labels\":{\"io.kubernetes.container.hash\":\"f932fb66\",\"io.kubernet
Jan 28 12:55:23 runcom.usersys.redhat.com dockerd-current[4199]: es.container.name\":\"POD\",\"io.kubernetes.container.restartCount\":\"0\",\"io.kubernetes.container.terminationMessagePath\":\"\",\"io.kubernetes.container.terminationMessagePolicy\":\"\",\"io.kubernetes.pod.name\":\"etcd\",\"io.kubernetes.pod.namespace\":\"default\",\"io.kubernetes.pod.terminationGracePeriod\":\"30\",\"io.kubernetes.pod.uid\":\"a63cff8a-e550-11e6-8c99-507b9d4141fa\"},\"NetworkingConfig\":null,\"OnBuild\":null,\"OpenStdin\":false,\"StdinOnce\":false,\"Tty\":false,\"User\":\"\",\"Volumes\":null,\"WorkingDir\":\"\"}"


Jan 28 12:55:23 runcom.usersys.redhat.com dockerd-current[4199]: time="2017-01-28T12:55:23.948539974+01:00" level=debug msg="form data: {\"AttachStderr\":false,\"AttachStdin\":false,\"AttachStdout\":false,\"Cmd\":null,\"Domainname\":\"\",\"Entrypoint\":[\"etcd\",\"--listen-client-urls=http://127.0.0.1:3379\",\"--advertise-client-urls=http://127.0.0.1:3379\",\"--data-dir=/var/lib/etcd\"],\"Env\":[\"KUBERNETES_SERVICE_PORT=443\",\"KUBERNETES_SERVICE_PORT_HTTPS=443\",\"KUBERNETES_PORT=tcp://10.0.0.1:443\",\"KUBERNETES_PORT_443_TCP=tcp://10.0.0.1:443\",\"KUBERNETES_PORT_443_TCP_PROTO=tcp\",\"KUBERNETES_PORT_443_TCP_PORT=443\",\"KUBERNETES_PORT_443_TCP_ADDR=10.0.0.1\",\"KUBERNETES_SERVICE_HOST=10.0.0.1\"],\"HostConfig\":{\"AutoRemove\":false,\"Binds\":[\"/etc/ssl/certs:/etc/ssl/certs\",\"/var/lib/etcd:/var/lib/etcd\",\"/etc/kubernetes:/etc/kubernetes/:ro\",\"/var/lib/kubelet/pods/a63cff8a-e550-11e6-8c99-507b9d4141fa/volumes/kubernetes.io~secret/default-token-gvxcc:/var/run/secrets/kubernetes.io/serviceaccount:ro,Z\",\"/var/lib/kubelet/pods/a63cff8a-e550-11e6-8c99-507b9d4141fa/etc-hosts:/etc/hosts:Z\",\"/var/lib/kubelet/pods/a63cff8a-e550-11e6-8c99-507b9d4141fa/containers/etcd/692fbb22:/dev/termination-log:Z\"],\"BlkioDeviceReadBps\":null,\"BlkioDeviceReadIOps\":null,\"BlkioDeviceWriteBps\":null,\"BlkioDeviceWriteIOps\":null,\"BlkioWeight\":0,\"BlkioWeightDevice\":null,\"CapAdd\":null,\"CapDrop\":null,\"Cgroup\":\"\",\"CgroupParent\":\"\",\"ConsoleSize\":[0,0],\"ContainerIDFile\":\"\",\"CpuCount\":0,\"CpuPercent\":0,\"CpuPeriod\":0,\"CpuQuota\":0,\"CpuShares\":204,\"CpusetCpus\":\"\",\"CpusetMems\":\"\",\"Devices\":[],\"DiskQuota\":0,\"Dns\":null,\"DnsOptions\":null,\"DnsSearch\":null,\"ExtraHosts\":null,\"GroupAdd\":null,\"IOMaximumBandwidth\":0,\"IOMaximumIOps\":0,\"IpcMode\":\"container:2b4df020a63fa9796c860a065135e06affd372d38dc9e323ca66c0fe010de469\",\"Isolation\":\"\",\"KernelMemory\":0,\"Links\":null,\"LogConfig\":{\"Config\":null,\"Type\":\"\"},\"Memory\":0,\"MemoryReservation\":0,\"MemorySwap\":-1,\"MemorySwappiness\":null,\"NetworkMaximumBandwidth\":0,\"NetworkMode\":\"con
Jan 28 12:55:23 runcom.usersys.redhat.com dockerd-current[4199]: tainer:2b4df020a63fa9796c860a065135e06affd372d38dc9e323ca66c0fe010de469\",\"OomKillDisable\":null,\"OomScoreAdj\":999,\"PidMode\":\"\",\"PidsLimit\":0,\"PortBindings\":null,\"Privileged\":false,\"PublishAllPorts\":false,\"ReadonlyRootfs\":false,\"RestartPolicy\":{\"MaximumRetryCount\":0,\"Name\":\"\"},\"SecurityOpt\":[\"seccomp=unconfined\",\"label:type:spc_t\"],\"ShmSize\":6.7108864e+07,\"StorageOpt\":null,\"UTSMode\":\"\",\"Ulimits\":null,\"UsernsMode\":\"\",\"VolumeDriver\":\"\",\"VolumesFrom\":null},\"Hostname\":\"\",\"Image\":\"gcr.io/google_containers/etcd-amd64<strong i="7">@sha256</strong>:b7b54201ba7ae22e1b7993d86d90615646a736a23abd8561f6012bb0e3dcc075\",\"Labels\":{\"io.kubernetes.container.hash\":\"f46ae33b\",\"io.kubernetes.container.name\":\"etcd\",\"io.kubernetes.container.restartCount\":\"0\",\"io.kubernetes.container.terminationMessagePath\":\"/dev/termination-log\",\"io.kubernetes.container.terminationMessagePolicy\":\"File\",\"io.kubernetes.pod.name\":\"etcd\",\"io.kubernetes.pod.namespace\":\"default\",\"io.kubernetes.pod.terminationGracePeriod\":\"30\",\"io.kubernetes.pod.uid\":\"a63cff8a-e550-11e6-8c99-507b9d4141fa\"},\"NetworkingConfig\":null,\"OnBuild\":null,\"OpenStdin\":false,\"StdinOnce\":false,\"Tty\":false,\"User\":\"\",\"Volumes\":null,\"WorkingDir\":\"\"}"

Anda dapat melihat (baik, temukan) dari atas bahwa wadah jeda dibuat tanpa label spc_t . Wadah etcd malah dibuat dengan label spc_t .
Di buruh pelabuhan, ketika sebuah wadah bergabung dengan namespace ipc dari yang lain, ia mendapat label selinux dari wadah target. Dalam hal ini, buruh pelabuhan mendapatkan label dari wadah jeda, yaitu container_t . Itu kemudian menambahkannya ke label keamanan etcd yaitu spc_t . Akhirnya Anda memiliki keduanya dan segalanya meledak.

Jadi, @rhatdan , pertanyaan saya adalah, apa yang harus kita lakukan? haruskah kubernetes menjalankan wadah jeda dengan spc_t juga sehingga tidak default ke container_t atau wadah etcd harus mengganti label wadah jeda jika etcd memilikinya? (dalam hal ini memiliki spc_t ).

Semoga semuanya jelas.

Jika aplikasi ditentukan untuk dijalankan sebagai spc_t, maka jeda dan semua wadah harus dijalankan sebagai spc_t.

Masalah buruh pelabuhan, mengatakan bahwa label:type :spc_t sedang diteruskan? Alih-alih label= type:spc_t ? Jadi itu adalah salah satu masalah ini yang menyebabkan masalah.

Menemukan ini dengan

@dgoodwin apakah Anda tahu di mana opsi keamanan pod diturunkan untuk membuat wadah jeda? Opsi keamanan dari pod tersebut harus diterapkan ke wadah jeda juga atau semuanya meledak karena label tersebut dapat berbicara satu sama lain.

Menemukan bahwa opsi keamanan pod tidak ada di sini https://Gist.githubusercontent.com/dgoodwin/1c19d2ad184ff792f786fec3cd137d0b/raw/beaaaa466b1073cacf4ec92f8ade9da28ad3233e/etcd.json bahkan jika di dalam containers ada label selinux.

Bagaimana kalian mengekstrak label selinux dari wadah di containers di PodSpec? container di containers di PodSpec perlu memiliki beberapa cara untuk menyetujui label _a_ selinux saja dan label itu juga harus digunakan untuk container infra.

Mungkin ada bug di runc saat mengatur label proses awal, saya kira. menemukannya

@runcom Bug akan ada di docker atau k8s. runc hanya menerapkan apa pun yang diturunkan. Apakah kita memastikan bahwa semua kontainer di dalam pod mendapatkan label yang sama?

@runcom Bug akan ada di docker atau k8s. runc sederhana hanya menerapkan apa pun yang diturunkan. Apakah kita memastikan bahwa semua kontainer di dalam pod mendapatkan label yang sama?

Maksud saya, ada bug lain dengan label selinux _in docker_. Label tidak diterapkan pada proses dengan benar.

Baiklah, masalahnya adalah wadah dalam pod harus memiliki label selinux yang sama dan tidak masuk akal untuk memiliki label yang berbeda untuk setiap wadah dalam pod. Sudah ada label selinux tingkat pod dan setiap wadah harus menggunakannya, bahkan wadah infra.

Apakah ada yang setuju dengan itu? Dalam hal ini, mengapa Anda dapat menentukan label selinux untuk container di dalam pod? Itu seharusnya menjadi kesalahan bagi saya.

@liggitt @pmorie tidak yakin siapa lagi... saat ini SecurityContext adalah objek API container . Tapi buruh pelabuhan, @runcom dan @rhatdan mengatakan bahwa itu pasti objek level pod ...

Apakah kita perlu memindahkannya dari container ke pod ? Yang jelas akan menjadi masalah API, tetapi jika buruh pelabuhan tidak bisa menanganinya di tingkat wadah ...

Saya kira agar akurat, saya harus mengatakan itu dapat diatur di pod dan container . Tetapi jika container selalu diabaikan dan hanya dibagikan dengan wadah pause (yang saya yakini hanya diatur pada level pod ), haruskah kita menyingkirkannya di container tingkat?

@eparis , Bagaimana kalau memiliki satu di tingkat pod dan mengizinkan penggantian dalam wadah di masa mendatang jika kami memiliki kebijakan untuk itu?

Saya yakin itu karena Anda mungkin memiliki beberapa wadah dan jika ada wadah yang menentukan label yang berbeda, mana yang akan Anda pilih? Saya kira poin utamanya adalah, pod sebagai unit seharusnya hanya menentukan opsi semacam ini. Wadah dalam pod terikat pada batasan pod ini, apa pun yang terjadi, kan?

Saya percaya hari ini konteks keamanan tingkat pod (jika ditentukan) diterapkan ke semua wadah. Jika konteks keamanan level container didefinisikan, kube mencoba untuk menimpa konteks level pod. Apa yang saya dengar dari kalian adalah bahwa konteks keamanan tingkat wadah selalu ditimpa oleh konteks wadah pause . dan container pause selalu == konteks keamanan tingkat pod. Jika tidak ada konteks keamanan tingkat pod, wadah jeda mendapatkan default buruh pelabuhan dan dengan demikian konteks keamanan tingkat wadah (lainnya) diabaikan...

jadi hari ini konteks keamanan kontainer tidak berguna, membingungkan, dan tidak pernah berfungsi ...

Haruskah buruh pelabuhan mulai menolak definisi wadah yang mencoba mengatur label selinux yang akan diabaikan (karena beberapa ruang nama bersama)? Biasanya SELinux sangat hebat dalam menolak situasi yang tidak valid alih-alih membuat pengguna percaya bahwa mereka memiliki properti keamanan yang tidak mereka miliki.

Ya, kami dapat mengencangkan buruh pelabuhan untuk menolak konfigurasi SELinux yang tidak valid jika ada ruang nama yang dibagikan.

@smarterclayton Anda mungkin harus membaca ini juga. Pada dasarnya definisi selinux tingkat wadah telah berfungsi di masa lalu tetapi dilanggar oleh 1.12.5 dan 1.13

(salah ketik dan saya mengedit komentar terakhir). Definisi selinux level CONTAINER tidak pernah berhasil.

Saya baru saja mencoba banyak kombinasi, dimulai dengan docker-1.12.1-13.git9a3752d.fc25.x86_64
dan container-selinux-2.2-2.fc25.noarch, memang, container-selinux tidak membuat perbedaan.

Semuanya berjalan hingga docker-1.12.4.

Saya pergi untuk melihat apa yang berubah antara .3 dan .4 dan sepertinya kalian ada dalam kasus ini: https://github.com/docker/docker/pull/26792/commits/4c10c2ded38031b20f5a0a409dd24643625fa878 :)

Perbaikan dilakukan pada docker-1.13 yang di-porting kembali ke docker-1.12 yang mengungkapkan bug di k8s. Pada dasarnya pod dan semua container di dalamnya, harus dijalankan sebagai konteks SELinux yang sama. Saat ini k8s tidak mengatur spc_t ke wadah jeda. Ketika proses container ditambahkan ke pause container, proses tersebut berbagi namespace IPC yang sama. Docker sekarang menetapkan label SELinux dari wadah jeda ke wadah yang baru dibuat, yang merupakan perilaku yang diharapkan. Dalam POD kita harus menjalankan semua container dengan label SELinux yang sama. Jika kami memperbaiki k8s untuk menetapkan label saat membuat POD, semuanya akan berfungsi.

@eparis Saya kira secara teoritis kami dapat mengizinkan beberapa label untuk ditetapkan, dan dapat memeriksa buruh pelabuhan jika label diatur sebelum mengatur label wadah agar sesuai dengan wadah tempat ia bergabung dengan IPC Namespace.

Saya bisa melihat di mana Anda mungkin ingin menjalankan wadah utama yang dikunci, tetapi mungkin wadah mobil samping dengan kebijakan yang lebih longgar.

Memindahkan securityContext dari container ke pod spec memungkinkan container berjalan dengan baik, saya akan mengirimkan tambalan untuk kubeadm untuk menaikkan level ini untuk sementara waktu sementara ini diselesaikan. Terima kasih semua atas bantuannya untuk mencari tahu apa yang salah dan di mana.

Ya, terima kasih banyak atas penyelidikan ini! Saya seorang noob di selinux (belum pernah menggunakannya, saya lebih dari seorang pria debian), jadi upaya ini sepadan dengan bobotnya dalam emas.

Saya kira kita mengharapkan resolusi untuk ini di k8s v1.6, bukan?

Juga, apakah penyedia jaringan seperti weave, flannel, dll. menambahkan aturan selinux ini juga agar pemasangan hostpath mereka berfungsi dengan baik juga? Jika itu masalahnya, kami harus memberi tahu mereka tepat waktu untuk rilis berikutnya.

Terima kasih semua untuk melihat ini. Jadi untuk rekap, beri tahu saya jika saya salah membacanya:

1 Masalah dengan format label ":" vs"=" dikerjakan di sini: # https://github.com/kubernetes/kubernetes/pull/40179
2 Masalah dengan label yang dilampirkan dua kali, juga ditangani di PR di atas
3 Parsing label seperti yang dilaporkan oleh @runcom , ditangani di sini # https://github.com/opencontainers/runc/pull/1303
4 Diskusi yang lebih luas tentang apakah operasi keamanan harus bekerja pada level container di dalam pod atau hanya dengan pod.

@luxas Saya pertama kali mencoba memperbaiki kubeadm dan kemudian melihat apa yang sebenarnya salah dengan penyedia jaringan seperti weave, flannel, canal, calico dan romana, mungkin masalah yang sama, tapi kami harus menentukan dulu saya pikir, sehingga kami dapat memberi tahu mereka apa yang harus diperbaiki.

3 Parsing label seperti yang dilaporkan oleh @runcom , ditangani di sini #opencontainers/runc#1303

ini hanya untuk buruh pelabuhan > 1.12.6 - buruh pelabuhan di Fedora/RHEL memiliki 1.12.6 yang menerapkan label dengan benar

Saya percaya hari ini konteks keamanan tingkat pod (jika ditentukan) diterapkan ke semua wadah. Jika konteks keamanan level container didefinisikan, kube mencoba untuk menimpa konteks level pod

Ini benar. Ini dilakukan di penyedia konteks keamanan dengan metode DetermineEffectiveSecurityContext .

Pada dasarnya definisi selinux tingkat wadah telah berfungsi di masa lalu tetapi dilanggar oleh 1.12.5 dan 1.13

Ya, kami dapat mengencangkan buruh pelabuhan untuk menolak konfigurasi SELinux yang tidak valid jika ada ruang nama yang dibagikan.

@pmorie @mrunalp @eparis - bantu saya memahami arah yang benar untuk penyedia SC dalam skenario ini. Kedengarannya seperti kami selalu berbagi namespace IPC dengan wadah jeda yang:

1. jika ada label selinux pada wadah, itu perlu diterapkan ke wadah jeda untuk membagikan ruang nama IPC
2. pengaturan per wadah tidak masuk akal jika ada lebih dari satu wadah di pod dengan pengaturan SELinux dan pengaturan itu tidak cocok?

jika item 2 benar maka saya pikir itu adalah argumen yang kuat untuk hanya memiliki pengaturan level pod.

Saya berpendapat bahwa buruh pelabuhan perlu memulai wadah jeda dengan konteks keamanan tingkat pod (jika ditentukan). Itu perlu memulai kontainer aktual dengan konteks keamanan kontainer (jika ditentukan) mundur ke konteks tingkat pod (jika ditentukan) dan kemudian kembali ke 'dibagikan dengan jeda'. (jika tidak ditentukan)

Saya tidak mengerti mengapa ruang nama IPC bersama harus relevan dengan diskusi ini. Jika pengguna mendefinisikan kombinasi konteks yang tidak diizinkan selinux untuk berfungsi, maka semuanya tidak akan berfungsi. Tetapi buruh pelabuhan tidak boleh 'menimpa' apa pun yang diminta pengguna.

Saya berpendapat bahwa buruh pelabuhan perlu memulai wadah jeda dengan konteks keamanan tingkat pod (jika ditentukan). Itu perlu memulai kontainer aktual dengan konteks keamanan kontainer (jika ditentukan) mundur ke konteks tingkat pod (jika ditentukan) dan kemudian kembali ke 'dibagikan dengan jeda'. (jika tidak ditentukan)

Lalu saya pikir tidak ada yang bisa dilakukan di sisi penyedia. Seharusnya sudah mengatur pengaturan pause container ke tingkat pod SC jika ditentukan dan container aktual mendapatkan penggabungan pod + container override yang berarti harus berbagi pengaturan dengan pause jika hal-hal ditentukan pada tingkat pod dan bukan tingkat container.

Jika pengguna mendefinisikan kombinasi konteks yang tidak diizinkan selinux untuk berfungsi, maka semuanya tidak akan berfungsi. Tetapi buruh pelabuhan tidak boleh 'menimpa' apa pun yang diminta pengguna.

Setuju. Terima kasih!

Ya @eparis benar. Saya harus mendapatkan tambalan ke buruh pelabuhan untuk menangani pelabelan dengan benar. Kita perlu mengizinkan fleksibilitas pengguna (IE Kemampuan untuk merusak sistemnya jika dia mau.)

Kasus defaultnya adalah bahwa semua proses container yang berbagi namespace IPC yang sama memiliki label SELinux yang sama, tetapi jika pengguna meminta untuk mengganti label, itu harus diizinkan.

Masalah dalam kasus ini, meskipun saya tidak bisa meletakkan jari saya di atasnya, tampaknya sedikit lebih rumit.
Opsi keamanan tidak ditimpa tetapi ditambahkan dua kali.

Anda sebenarnya dapat melihatnya sedikit ketika perbaikan ini tidak diterapkan:

1 Masalah dengan format label ":" vs"=" yang dikerjakan di sini: #kubernetes/kubernetes#40179

buruh pelabuhan memeriksa wadah jeda:

"SecurityOpt": [
            "seccomp=unconfined",
            "label:type:spc_t"
        ],

Docker memeriksa wadah etcd:

  "SecurityOpt": [
            "seccomp=unconfined",
            "label:type:spc_t",
            "label=user:system_u",
            "label=role:system_r",
            "label=type:spc_t",
            "label=level:s0:c23,c719"

Label dengan format "label:" berasal dari manifes yang digunakan untuk memulai penerapan pod etcd. Setidaknya saya pikir begitu.

Kubelet atau buruh pelabuhan tampaknya menambahkan yang lain, yang agak masuk akal seperti halnya untuk file gambar yang ditempatkan di /var/lib/docker/containers dan /var/lib/kubelet/pods

Dari diskusi di #kubernetes/kubernetes#40179 kita tahu bahwa buruh pelabuhan tidak mencegah penambahan lebih banyak opsi keamanan, maka sebenarnya harus diizinkan.
Tapi di mana atau bagaimana penambahan ini terjadi, saya tidak tahu.

@eparis @rhatdan Bisakah Anda membantu memeriksa masalah ini juga? Mengapa seLinuxOptions di tingkat pod dan tingkat wadah memiliki hasil yang berbeda? terima kasih https://github.com/kubernetes/kubernetes/issues/37809

Saya memiliki permintaan tarik untuk membantu memperbaiki masalah ini untuk buruh pelabuhan
https://github.com/docker/docker/pull/30652

Kami telah menjelaskan masalah ini.

Di buruh pelabuhan standar jika Anda menambahkan wadah dengan satu label dan kemudian menambahkan wadah lain yang ingin Anda gabungkan dengan IPC Namespace yang sama, buruh pelabuhan akan mengambil label wadah pertama dan menetapkannya ke wadah kedua. Dengan cara ini SELinux tidak akan memblokir akses ke IPC yang dibuat oleh container pertama yang perlu digunakan oleh container kedua.

Label SELinux type/mcs pada Pod Level menetapkan label untuk container pause . Label Jenis/MCS SELinux pada label wadah menetapkannya untuk setiap wadah yang bergabung dengan wadah pause .
Jika Kubernetes tidak menetapkan label untuk wadah pause ia akan diberi label seperti container_t:s0:c1,c2. Kemudian kubernetes mencoba menambahkan wadah dengan label seperti spc_t:s0. Dalam versi docker yang lebih lama, buruh pelabuhan akan melihat bahwa bidang security-opt telah disetel dan tidak memanggil kode untuk menggabungkan label SELinux. Tetapi ini menyebabkan masalah dengan orang-orang yang mengatur seccomp, pada dasarnya kami tidak akan mendapatkan perilaku yang diharapkan dari dua wadah yang berbagi label SELinux yang sama, jika ada bidang non label yang disetel di security-opt. Sebuah tambalan digabungkan ke hulu untuk mengambil cara pemeriksaan security-opt . Ini memperkenalkan bug di mana jika pengguna menentukan opsi keamanan label SELinux dari wadah yang bergabung dengan wadah lain untuk mengabaikan opsi keamanan.

Intinya:

Docker lama, jika pause /POD container masuk tanpa label, maka container_t:s0:c1,c2. Jika container baru dikirim untuk bergabung dengan container pause , dengan spc_t:s0. Docker akan meluncurkan wadah kedua dengan spc_t:s0, dan k8s senang. Setelah memperbaiki wadah kedua berakhir dengan container_t:s0:c1,c2 dan k8s yang lebih ketat tidak bahagia. Perbaikan yang benar untuk masalah di sisi k8s adalah dengan menyetel label pause/POD ke spc_t:s0 dan wadah yang ditambahkan akan cocok dengan spc_t:s0.

Dengan tambalan saya di atas, kami akan mengizinkan pengguna untuk menentukan label selinux alternatif untuk setiap wadah yang ditambahkan, tetapi ini hanya boleh dilakukan oleh orang yang memahami cara kerja kurungan SELinux. IE Anda mungkin ingin mengatur pod multi-kontainer di mana satu kontainer memiliki hak lebih/kurang dari kontainer yang digabungnya.

Tambalan buruh pelabuhan akan memperbaiki masalah k8s, juga tetapi tidak menghilangkan fakta bahwa wadah jeda mungkin harus berjalan dengan label SELinux yang sama dengan wadah yang bergabung dengannya.

@rhatdan terima kasih banyak

Jadi.........bagaimana cara mengujinya? @dgoodwin @jasonbrooks @rhatdan @jessfraz?

Maaf tidak berpengalaman dalam membangun barang, tapi bersedia melakukannya.... Saya punya beberapa petunjuk, tetapi bantuan apa pun diterima.
kubernetes/kubernetes#40179 dipindahkan.....jadi bagaimana cara memasukkannya?

Terima kasih

Ok mengetahuinya selama akhir pekan, tetapi masih tidak berfungsi.

Ok, build kubeadm dan kubelet (bagian ini saya lupa, maka komentar terakhir saya) sendiri dari master branch dengan kubernetes/kubernetes#40903 digabung dan berfungsi dengan selinux enforcing, bahkan dengan weave running, meskipun weave tidak berjalan dengan benar. Itu adalah masalah menenun yang harus ditangani nanti serta penyedia lain yang masih harus saya uji.
Tapi setidaknya tidak ada penolakan selinux dengan penegakan selinux.

Mengenai entri ganda yang dirujuk dalam kubernetes/kubernetes#37807:

  "SecurityOpt": [
            "seccomp=unconfined",
            "label=type:spc_t",
            "label=user:system_u",
            "label=role:system_r",
            "label=type:spc_t",
            "label=level:s0:c210,c552"

Saya pikir itu berasal dari beberapa validasi ketika DeterminEffectiveSecurityContext dijalankan, seperti yang disebutkan @pweil-, dan baru saja ditambahkan daripada diganti sebagai opsi keamanan buruh pelabuhan. Karena buruh pelabuhan berjalan dengan semua opsi yang diteruskan tetapi hanya menggunakan opsi keamanan terakhir yang diteruskan, ini sepertinya berhasil. Tidak yakin apakah itu perilaku yang diharapkan untuk buruh pelabuhan, tapi itu masalah yang berbeda. @rhatdan mungkin ingin melihat lagi, mengenai buruh pelabuhan/ buruh pelabuhan#30652

Tidak yakin apakah kami harus menutup masalah, sampai kami mendapatkan rpm dari repo resmi, uji lagi dan seterusnya, uji jaringan pod terlebih dahulu, dan perbaiki, perbarui dokumen dll, sebelum menutup. Jadi beri tahu saya.

Terima kasih semua untuk memperbaiki ini :)

Ini terlihat benar, meskipun dengan tambalan yang saya miliki untuk buruh pelabuhan hulu, Anda hanya akan mendapatkan satu bidang "label= type:spc_t ".

@rhatdan pertanyaan, karena saya membangun buruh pelabuhan dengan tambalan Anda, mungkin saya tidak melakukannya dengan benar, tetapi saya pikir itu benar. Dan saya masih melihat ini.

perilaku ini tidak berubah:
docker run -ti --security-opt label= type:container_t --security-opt label= type:spc_t fedora sleep 5

 "MountLabel": "system_u:object_r:container_file_t:s0:c118,c497",
    "ProcessLabel": "system_u:system_r:spc_t:s0:c118,c497",

menggunting

"SecurityOpt": [
"label= type:container_t ",
"label= ketik:spc_t "

itu berjalan dengan tambalan Anda, tidak ada yang lebih bijaksana.

Docker menerima itu, apakah tambalannya melanggar itu? Apakah ada kasus penggunaan yang waras bahwa buruh pelabuhan harus dapat melakukan itu?

Dari masalah ini, jika buruh pelabuhan mengubahnya, melihat kita (kubernetes pod runtime ) akhirnya kita menggandakan label, yang menurut saya berasal dari validasi di kubelet, jika Anda melanggar fakta buruh pelabuhan menerima lebih banyak opsi maka seharusnya...yah rusak lagi.

Lihat apakah waras, kita harus dapat menjalankan pod dengan opsi keamanan yang berbeda untuk kontainer di dalam pod, dan saya pikir itu tujuannya, yang seharusnya mungkin, tetapi diperlukan penyelarasan. Docker dan kubernetes tidak dapat memiliki harapan yang berbeda tentang ini.

Saya mungkin salah, menambahkan @eparis @dgoodwin @jasonbrooks @luxas @pweil- @pmorie

Perubahan saya bukan untuk mencegah itu meskipun kita mungkin harus melakukannya. Perubahan saya adalah memblokir wadah yang bergabung dengan IPC Namespace atau pid namespace yang lain

# docker run -d --name test fedora sleep 10
# docker run -d security-opt label=type:spc_t --ipc container:test fedora cat /proc/self/attr/current

Wadah kedua harus dijalankan sebagai spc_t. Di mana kode lama akan menjalankannya sebagai container_t. Ini pada dasarnya akan meniru dua kontainer yang berjalan di pod yang sama dengan label SELinux yang berbeda.

Terima kasih @rhatdan untuk klarifikasinya.

Menutup yang ini, karena perubahan yang diaktifkan rbac untuk jaringan pod dilacak #143

Tidak yakin tentang label ganda, tampaknya interaksi antara kubernetes/kubelet dan buruh pelabuhan seperti yang disebutkan di atas.

Pokoknya mengajukan ini untuk buruh pelabuhan # https://github.com/docker/docker/issues/31328

Terima kasih semuanya,

Saya menjalankan dengan Enforcing dan tidak memiliki masalah dengan flanel, FYI. Saya bertanya-tanya apakah konfigurasi SELinux tertentu merusaknya dan yang lainnya tidak? Bukan ahli SELinux btw.