<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    K8S中各組件和Kube Apiserver通信時的認證和鑒權

    VSole2022-06-08 15:37:11

    背景


    和master節點kube api-server通信的組件有很多,包括:

    • kubelet

    • calico

    • scheduler

    • kubectl

    • 某些pod可能會和kube api-server通信

    這些組件和api-server通信時用的是什么身份,可以操作哪些api資源呢?


    本文使用的k8s集群是用kubekey[1]搭建,命令是./kk create cluster --with-kubernetes v1.21.5 --with-kubesphere v3.2.1




    Kubectl的身份和權限


    Kubectl用的是什么身份?


    Kubectl默認會用到.kube/config配置,其中包含證書信息。



      root@ip-172-31-14-204:~# cat .kube/config  apiVersion: v1  ...  users:  - name: kubernetes-admin    user:      client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURJVENDQWdtZ0F3SUJBZ0lJSm9rTE5qWVk0UG93RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TWpBMU1qVXdNRE13TURWYUZ3MHlNekExTWpVd01ETXdNRFphTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTI5L25vcEVJWE9JVXl0MngKRUFETUNod01idkhaWU90c2xYdFBsYnNYRXJPOXpmYzBIMi9UV2p2dUFHUDRwaVhPaG5sSnYvRmtKTVVCbk1HWgpmV3VrdU1vTStOSDZkMERFVjlsMUNYUk9BOEhlRStacXBtYmVvbTV3SWdsYlZIeXFzdTZNb2VySTZkYnFqcEdSCmpJUzVyb0tNQU94OFNYRlJxUFZaaEtIdkhFUTk2REt1UWNmMU84ZzlWKzVjYzQwZ295UzBsOHAxOWtBdU1JeTAKQktPWGZxTTMyRkNSSWZKOWJTSzZPQTBDek8wbWlJK0pidVhMMWFzNkE5M08xdWZCdUxOdURTTmZSR015WjJoQgpTdGU3eEZyOFZQRlFsRmJBUklBRnJjK0RvMXBUUk1xZ09kUS8xZVE0bk5iNXRRa0hnZG9raERVZ2owd2hHTmV6Clc0RFlrUUlEQVFBQm8xWXdWREFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JUZnZPL1VlcDhWbnVmS3Q5QVpOY0tFV05vbApWakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBdGQ5Q1RwajdEdUw2NDIxanhhMlYrcEhCV2tqRVhqaXdMQUdxCmI4UVpPT2llT2xUcjNPTVVXWWw1NEJpd3N2WmkxYi9pRDlMalhjUnhxR0d1ZytMUS9zNnVRVjBwSWhpL2U1MloKclB6Vm83V2VmSURZQm44RWhwSmsvbjdXYjhyRDJLUmNqNnRNanNFS3ViVkNSRXQyeWdYeFhvSnJ6a21xTkgvSwpGMFdqOGtFV2ZKVENQZnNmV1laNDBKMDJhbGZ4d05QQ080K1BoRDhoSm9xK1h6aitCNWl0TDVNZ2o0ZWFOZHpsCkxnUk4zc3hMZ0QvOVA4MW1NdTBnVDZ1V3d6c0U4VXZGdE9kOXkzOG50Q25HVUF5U2pTU1NOY0thRVVhWTd5KzIKTGxZeXFBZmJGN29pdEJsOWxSSnZmL2thR2trdGJoQ0dnNVk3eVMxSUVWNFVJdTZFb3c9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==  ...
    


    可以看到這個證書的CN是kubernetes-admin,O是system:masters。根據文檔[2]可以知道,這表示證書代表的用戶是kubernetes-admin,用戶組是system:masters。



      root@ip-172-31-14-204:~# echo LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURJVENDQWdtZ0F3SUJBZ0lJSm9rTE5qWVk0UG93RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TWpBMU1qVXdNRE13TURWYUZ3MHlNekExTWpVd01ETXdNRFphTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTI5L25vcEVJWE9JVXl0MngKRUFETUNod01idkhaWU90c2xYdFBsYnNYRXJPOXpmYzBIMi9UV2p2dUFHUDRwaVhPaG5sSnYvRmtKTVVCbk1HWgpmV3VrdU1vTStOSDZkMERFVjlsMUNYUk9BOEhlRStacXBtYmVvbTV3SWdsYlZIeXFzdTZNb2VySTZkYnFqcEdSCmpJUzVyb0tNQU94OFNYRlJxUFZaaEtIdkhFUTk2REt1UWNmMU84ZzlWKzVjYzQwZ295UzBsOHAxOWtBdU1JeTAKQktPWGZxTTMyRkNSSWZKOWJTSzZPQTBDek8wbWlJK0pidVhMMWFzNkE5M08xdWZCdUxOdURTTmZSR015WjJoQgpTdGU3eEZyOFZQRlFsRmJBUklBRnJjK0RvMXBUUk1xZ09kUS8xZVE0bk5iNXRRa0hnZG9raERVZ2owd2hHTmV6Clc0RFlrUUlEQVFBQm8xWXdWREFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JUZnZPL1VlcDhWbnVmS3Q5QVpOY0tFV05vbApWakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBdGQ5Q1RwajdEdUw2NDIxanhhMlYrcEhCV2tqRVhqaXdMQUdxCmI4UVpPT2llT2xUcjNPTVVXWWw1NEJpd3N2WmkxYi9pRDlMalhjUnhxR0d1ZytMUS9zNnVRVjBwSWhpL2U1MloKclB6Vm83V2VmSURZQm44RWhwSmsvbjdXYjhyRDJLUmNqNnRNanNFS3ViVkNSRXQyeWdYeFhvSnJ6a21xTkgvSwpGMFdqOGtFV2ZKVENQZnNmV1laNDBKMDJhbGZ4d05QQ080K1BoRDhoSm9xK1h6aitCNWl0TDVNZ2o0ZWFOZHpsCkxnUk4zc3hMZ0QvOVA4MW1NdTBnVDZ1V3d6c0U4VXZGdE9kOXkzOG50Q25HVUF5U2pTU1NOY0thRVVhWTd5KzIKTGxZeXFBZmJGN29pdEJsOWxSSnZmL2thR2trdGJoQ0dnNVk3eVMxSUVWNFVJdTZFb3c9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== | base64 -d | openssl x509  -noout -text  Certificate:      ...          Subject: O = system:masters, CN = kubernetes-admin
    


    那這個證書代表的用戶能操作哪些資源呢?



    能操作哪些資源呢?


    這個需要看"用戶kubernetes-admin"、"用戶組system:masters"在集群中綁定了什么"角色"。

    可以看到它綁定了"ClusterRole/cluster-admin",這個角色可以對所有資源做任意操作。



      root@ip-172-31-14-204:~# kubectl get ClusterRoleBinding -A -o wide | grep system:masters  cluster-admin                                          ClusterRole/cluster-admin                                                          33h                                    system:masters
    


    可以通過kubectl get ClusterRole/cluster-admin -o yaml查看角色的權限。


    所以,.kube/config證書中代表的用戶身份可以對所有資源做任意操作。





    Kube-scheduler的身份和權限


    Kube-scheduler用的是什么身份?


    在master節點上查看scheduler進程,可以"大膽猜測"用的是/etc/kubernetes/scheduler.conf中的證書信息。


    在我的k8s環境中,kube-scheduler是運行在pod中的,不過pod和宿主機的/etc/kubernetes/scheduler.conf文件是一樣的。




      root@ip-172-31-14-33:~# ps aux|grep kube-scheduler  root     51897  0.2  0.7 753012 57736 ?        Ssl  May25   3:59 kube-scheduler --authentication-kubeconfig=/etc/kubernetes/scheduler.conf --authorization-kubeconfig=/etc/kubernetes/scheduler.conf --bind-address=0.0.0.0 --feature-gates=RotateKubeletServerCertificate=true,TTLAfterFinished=true,ExpandCSIVolumes=true,CSIStorageCapacity=true --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true --port=0
    


    查看證書的Subject信息,可以看到用戶是system:kube-scheduler



      root@ip-172-31-14-33:~# echo LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUREVENDQWZXZ0F3SUJBZ0lJUWdERWp2Q3pZdGd3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TWpBMU1qVXdNRE13TURWYUZ3MHlNekExTWpVd01ETXdNRFphTUNBeApIakFjQmdOVkJBTVRGWE41YzNSbGJUcHJkV0psTFhOamFHVmtkV3hsY2pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCCkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUx3blRITU9scnMzMThjRVdoMkZFOUlmMDN1SXBTRmUxUU9jeFhXOFFmb1IKcUp6bS96ZWpwSUxNci82bXRERnp1WFhDWnhVNjA3eWN2VkprKzFCRzJLQjFtTEZDa0JlWlJVQTBjMk5udEhtVQpmVWkwNjhqeHdCeWFEbXlha2N0NENoT0I3K0xGT3I5WHozQ0owcUxaTXp0YnAxUk5nTWR4aE9IQmZZRFlXdWZ1Ckk3b3R0THdlQlZ0R3RNQlNjb1pOZ1lyWEFyb0MyVzBSYkVNUVhYV0pVMjFXUEdyRkxFQjVpZWo5SjRKWUxuRGQKdDcxK0NoWWQxcXA0bVJmZHhIcXB6dG8vSzdEWWo0UzJVS1BleGUxN2QwR25CcnJYajVWb2FPckhaWVRpNm5xRgptZk81eEdySEtqR1lncEdnYlBUTFNjbFdlcVMzbi9OQThCUE96OElEeWY4Q0F3RUFBYU5XTUZRd0RnWURWUjBQCkFRSC9CQVFEQWdXZ01CTUdBMVVkSlFRTU1Bb0dDQ3NHQVFVRkJ3TUNNQXdHQTFVZEV3RUIvd1FDTUFBd0h3WUQKVlIwakJCZ3dGb0FVMzd6djFIcWZGWjdueXJmUUdUWENoRmphSlZZd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQgpBRVdxaTY3M0tNZ0tyaHdPRTcxZm40YlBwUlJKY0hhdWNlaWF0d085S1dLRW9IbklRTWN5dlR5QW9DL3B1Y2RMCmN5MVNnVzZEdURjdERDTlhwdGNMc3VKaTltc3lXVFdWV09ONUgwUUpMTHBUblpoUnRUeU1rSU92MzdIekFHTHYKbFJVbzlaUWRuWEpmMS8yTlFsak5TUFNFZGwzYm1aRnh1ZjlDTFA3OVBqVWhCNzJET1N2RVJoYXBaanBCK0JxTwpHdjU1bEhyUG1nUGJicS90NndScUFEN1FSZ1M3ZnpOYjVOT0l3TU5pL29GU0k3anlNeEdleFJTcStrQWpUSHNZCnZlcUNSamszNkF6WUZSb0xsbFM3RURPZlVBWkJST3RicTN0dkpYM0NMemE5OVNyZlk3REpUL1c1N2dna0dFNkkKLzZNcUVOTzNTRlY0TzU2RmsvRGlxRTQ9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K | base64 -d |openssl x509  -noout -text  Certificate:      ...          Subject: CN = system:kube-scheduler
    


    可以看到"用戶system:kube-scheduler"綁定了兩個角色。



      root@ip-172-31-14-33:~# kubectl get ClusterRoleBindings -o wide |grep system:kube-scheduler  system:kube-scheduler                                  ClusterRole/system:kube-scheduler                                                  31h   system:kube-scheduler  system:volume-scheduler                                ClusterRole/system:volume-scheduler                                                31h   system:kube-scheduler
    




    Kubelet的身份和權限


    Kubelet用的是什么身份?



      root@ip-172-31-14-204:~# ps aux|grep kubelet  root     54396  7.7  2.8 1966128 113860 ?      Ssl  08:14  29:54 /usr/local/bin/kubelet ... --kubeconfig=/etc/kubernetes/kubelet.conf ...
    


    在worker節點上可以看到kubelet進程參數,api-server信息在/etc/kubernetes/kubelet.conf文件中

    可以看到是通過證書認證的



      root@ip-172-31-14-204:/etc/kubernetes/manifests# cat /etc/kubernetes/kubelet.conf  apiVersion: v1  ...  users:  - name: system:node:ip-172-31-14-33    user:      client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem      client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
    


    查看證書的Subject信息,可以知道證書代表的"用戶"是"system:node:ip-172-31-14-204","用戶組"是"system:nodes"



      root@ip-172-31-14-204:~# openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -text  Certificate:      ...          Subject: O = system:nodes, CN = system:node:ip-172-31-14-204
    


    那這個kubelet的證書代表的用戶能操作哪些資源呢?它可以用來像"集群管理員"那樣創建pod嗎?



    kubelet能操作哪些資源?


    按照之前流程,我們來看一下"用戶system:node:ip-172-31-14-204"、"用戶組system:nodes"在集群中綁定了什么"角色"。



     root@ip-172-31-14-204:~# kubectl get ClusterRoleBinding -A|grep system:nodes  root@ip-172-31-14-204:~# kubectl get ClusterRoleBinding -A|grep "system:node:ip-172-31-14-204"  root@ip-172-31-14-204:~#
    


    會發現"用戶和用戶組"沒有綁定任何一個角色,這和kubectl、kube-scheduler就很不一樣了。

    在使用Node鑒權[3] 文檔中提到,kube apiserver對kubelet的鑒權比較特殊。

    當發現請求的用戶在system:nodes組中,用戶名是system:node:時,就限制這個請求只能做有限的操作,比如

    讀操作

    • services

    • pod

    • 綁定到當前node的pod的secret、configMap

    寫操作(如果開啟了NodeRestriction準入插件,就只能修改kubelet所在node的資源)

    • 創建節點、修改節點狀態

    • 創建pod、pod狀態

    似乎如果沒有開啟NodeRestriction準入插件,就能讓kubelet在任意node上創建pod。


    紅藍對抗中,如果能讓kubelet在任意node上創建pod,就能用來橫移。


    文檔中寫到,這里的能力可能隨著k8s版本變化而變化,以確保kubelet最小權限,默認安全。所以,kubelet到底能操作哪些資源,感覺還是來測試一下比較好,下面就來驗證一下kubelet的權限。



    驗證kubelet的權限


    我們先用kubelet配置文件覆蓋kubectl的默認配置,然后就可以用kubectl命令來驗證。



      root@ip-172-31-14-204:~# mv .kube/config .kube/config.bak  root@ip-172-31-14-204:~# ps aux|grep kubele  root     59075  7.9  2.7 1956332 108712 ?      Ssl  03:37   2:51 /usr/local/bin/kubelet ... --kubeconfig=/etc/kubernetes/kubelet.conf ...  root@ip-172-31-14-204:~# cp /etc/kubernetes/kubelet.conf .kube/config
    


    可以看到不能夠創建pod



     root@ip-172-31-14-204:~# kubectl run httpbin --image kennethreitz/httpbin  Error from server (Forbidden): pods "httpbin" is forbidden: pod does not have "kubernetes.io/config.mirror" annotation, node "ip-172-31-14-204" can only create mirror pod
    


    查看pod信息是可以的



      root@ip-172-31-14-204:~# kubectl get pods -A  NAMESPACE                      NAME                                               READY   STATUS      RESTARTS   AGE  default                        tail                                               1/1     Running     0          25h  kube-system                    calico-kube-controllers-846b5f484d-vzlhw           1/1     Running     0          27h  ...  root@ip-172-31-14-204:~# kubectl describe pod devops-27558900-m69pc -n kubesphere-devops-system  Name:         devops-27558900-m69pc  ...
    


    查看secret和configMap是不允許的



      root@ip-172-31-14-204:~# kubectl get secrets -A  Error from server (Forbidden): secrets is forbidden: User "system:node:ip-172-31-14-204" cannot list resource "secrets" in API group "" at the cluster scope: can only read namespaced object of this type  root@ip-172-31-14-204:~# kubectl get configmap  Error from server (Forbidden): configmaps is forbidden: User "system:node:ip-172-31-14-204" cannot list resource "configmaps" in API group "" in the namespace "default": No Object name found  root@ip-172-31-14-204:~#
    


    小結:kubelet證書可以用來查看pod信息,不能創建pod、不能查看所有命名空間的secret和configMap。看起來和文檔中的說明一致。





    calico


    calico用的是什么身份?



     root@ip-172-31-14-204:~# cat /etc/cni/net.d/calico-kubeconfig  # Kubeconfig file for Calico CNI plugin. Installed by calico/node.  ...  users:  - name: calico    user:      token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImV6bEstc2QtRTNTaE1ySFg2SWdxMjY2aHpkVFBEWU56SGdfaVdZRXZ4YncifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjg1MDIyOTAwLCJpYXQiOjE2NTM0ODY5MDAsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsInBvZCI6eyJuYW1lIjoiY2FsaWNvLW5vZGUtcWR0ZmIiLCJ1aWQiOiI4N2U4ZmM3ZC0yYTg5LTQ1OTgtOWQyOC1mZDYyNGIwODk2MDMifSwic2VydmljZWFjY291bnQiOnsibmFtZSI6ImNhbGljby1ub2RlIiwidWlkIjoiOTEzNzUwZWItYmRhNC00YjJmLTgxNjctNDZjOTkxNjk5YWRkIn0sIndhcm5hZnRlciI6MTY1MzQ5MDUwN30sIm5iZiI6MTY1MzQ4NjkwMCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmNhbGljby1ub2RlIn0.mF1Yek_sSBa2nlQIbdJlEZtv3anjIUFPFpj8Ta8Zn1t6vxYEZjswbPxrw-90sbEVGR30GWytUjr3X1tmjWTP0fL9ltAPvcM0tRg6MoLuGdC2uZFbt-zfKFEn42Yme-NuVOKO3K2otgZNt0ym0gYRT41wLCqOuKLq-SHAkHdvIOZ1eVAu0OsN3ccgSFf2nsuBqbDphd4ShqRPNXl1m66UEDlb4WiPmuSPuzRmMiV706YbBPxMUzn9Ve4o4IfBbeBufp_edSWPPW763EGqZmI7qZg-78SUbtAJ6m8Qkq6TrDIcaJbI3Mrl4EsrnE3v3MGMOogfXXs3-yU-NZl3ilQt6Q  ...
    


    可以看到用的是token令牌。這個token令牌是一個jwt字符串,base64解碼后的payload部分如下,可以看到"ServiceAccount"是calico-node,命名空間是kube-system



      {"aud":["https://kubernetes.default.svc.cluster.local"],"exp":1685022900,"iat":1653486900,"iss":"https://kubernetes.default.svc.cluster.local","kubernetes.io":{"namespace":"kube-system","pod":{"name":"calico-node-qdtfb","uid":"87e8fc7d-2a89-4598-9d28-fd624b089603"},"serviceaccount":{"name":"calico-node","uid":"913750eb-bda4-4b2f-8167-46c991699add"},"warnafter":1653490507},"nbf":1653486900,"sub":"system:serviceaccount:kube-system:calico-nodeIn0
    


    可以看到,這個"ServiceAccount"被綁定到了"ClusterRole/calico-node"角色。



      root@ip-172-31-14-204:/home/ubuntu# kubectl get clusterrolebinding -o wide|grep kube-system/calico-node  calico-node                                            ClusterRole/calico-node                                                            34h                                                                                      kube-system/calico-node
    


    pod


    pod用的是什么身份?


    大部分pod會掛載一個token在/var/run/secrets/kubernetes.io/serviceaccount/token位置,這個token也是一個jwt字符串。


      root@ip-172-31-14-204:/home/ubuntu# kubectl exec -ti tail -- sh  / # cat /var/run/secrets/kubernetes.io/serviceaccount/token  eyJhbGciOiJSUzI1NiIsImtpZCI6ImV6bEstc2QtRTNTaE1ySFg2SWdxMjY2aHpkVFBEWU56SGdfaVdZRXZ4YncifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjg1MDk4NTUwLCJpYXQiOjE2NTM1NjI1NTAsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJ0YWlsIiwidWlkIjoiYmQzZGRlZjAtODViYy00MmI4LThjZWYtMjQwZTkwMjViYWQ5In0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJkZWZhdWx0IiwidWlkIjoiZGI5YjQ5MGMtYzU5MS00NDc0LTljOTAtY2U3ZjZmMmRjYjYzIn0sIndhcm5hZnRlciI6MTY1MzU2NjE1N30sIm5iZiI6MTY1MzU2MjU1MCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6ZGVmYXVsdCJ9.L388ZKZWvHYf7Yvt6tA7t8k2QMYcsI9BDcYtoxAgOJiEiwf3LKFQmdH8KF4PnI0kjM3Bg80WztFznotwZqCwCNfXMVMl4_iLGHDAgVB3tsdv9ljZ9FUJbn52PD5aWHSWRqjpyQzv8_89dlnnbGQLHg4M8Ly4OkGuWUOnE1x6vgSa1MkjhrnrJEPnnJo5Fy_vyRdvO2A9iyGh7cC97Ns6WWFkeD7741wSkGkoNkZKqJTyfaa_KScprPiVPYuisi4HkYrP71NzZA_i34Dk-IsomySR4h2WWw_88-kfL_lWZ8PDu5NuVekZZ4xfIQjA6oDhXT_Hx4iIlhwVwgYuTW4V-g
    


    base64解碼后,payload中也能看到一個服務賬號ServiceAccount,這個ServiceAccount也有可能和一個"角色"綁定。你可以動手查看一下自己的pod。


    總結


    k8s中"X509 客戶證書"和"服務賬號令牌"應該是身份認證最常見的兩種方式,都能代表"用戶"或"用戶組"信息。

    大部分的組件(包括scheduler、calico、kubectl、pod)鑒權都是依賴RBAC模型,也就是"用戶或"用戶組"綁定的"角色"規定了能訪問哪些資源。

    kubelet的鑒權比較特殊,是依賴Node鑒權模型。


    用戶認證[4] 文檔中還提到api訪問控制的其他方法。

    kubernetes通信
    本作品采用《CC 協議》,轉載必須注明作者和本文鏈接
    Kubernetes通常被稱為“K8s”,是一種非常流行的開源容器編排系統,可以自動部署、擴展和管理容器化工作負載。
    一、前言 這篇文章可能出現一些圖文截圖顏色或者命令端口不一樣的情況,原因是因為這篇文章是我重復嘗試過好多次才寫的,所以比如正常應該是訪問6443,但是截圖中是顯示大端口比如60123這種,不影響閱讀和文章邏輯,無需理會即可,另外k8s基礎那一欄。。。本來想寫一下k8s的鑒權,后來想了想,太長了,不便于我查筆記,還不如分開寫,所以K8S基礎那里屬于湊數???寫了懶得刪(雖然是粘貼的:))
    從2022年1月到7月,Sysdig威脅研究團隊實施了一個全球蜜網系統,通過多個攻擊載體捕獲了大量漏洞。如何防范暴力破解DDoS攻擊首先,確保Web服務器免受暴力攻擊是很重要的。攻擊者的目標是訪問服務器或暫時使其失去響應。檢測賬戶接管欺詐主要的威脅檢測解決方案之一是監視應用程序的登錄頁面,以防止使用受損憑證對用戶帳戶進行未經授權的訪問。賬戶接管是一種在線非法活動,攻擊者在未經授權的情況下訪問用戶的賬戶。
    跨節點Pod通信則是三層虛擬網絡設備Tun,也就是flannel0。同理目的主機就會有UDP解包及轉發至Pod服務。還有VXLAN模式支持DirectRouting配置,DirectRouting=true是支持在相同子網情況下數據包直接通過路由轉發,與HOST-GW模式相同。但是HOST-GW模式只支持宿主機之間二層連接,要求集群中所以節點必須處于同一個網絡中
    CRI-O 允許你直接從 Kubernetes 運行容器,而不需要任何不必要的代碼或工具
    本文將引入一個思路:“在 Kubernetes 集群發生網絡異常時如何排查”。文章將引入 Kubernetes 集群中網絡排查的思路,包含網絡異常模型,常用工具,并且提出一些案例以供學習。其可能原因為Pod 的 DNS 配置不正確DNS 服務異常pod 與 DNS 服務通訊異常大數據包丟包:主要現象為基礎網絡和端口均可以連通,小數據包收發無異常,大數據包丟包。
    和master節點kube api-server通信的組件有很多,包括: kubelet calico scheduler kubectl 某些pod可能會和kube api-server通信 這些組件和api-server通信時用的是什么身份,可以操作哪些api資源呢? 本文使用的k8s集群是用kubekey[1]搭建,命令是./kk create cluster --with-
    展示在Kubernetes集群中的攻擊和防御思路
    NSA和CISA聯合發布Kubernetes安全加固建議。指南稱,Kubernetes環境被黑的主要誘因是供應鏈攻擊、惡意攻擊者和內部威脅。雖然管理員無法應對這3種威脅,但可以通過避免錯誤配置、減小安全風險等方式來加固Kubernetes系統。針對Kubernetes系統安全風險的防護措施包括掃描容器和pod的bug和錯誤配置、使用最小權限來運行pod和容器、進行網絡隔離、強認證、防火墻等。
    對于在共享基礎設施上運行的容器化應用程序來說,安全是至關重要的。隨著越來越多的組織將其容器工作負載轉移到Kubernetes,K8s已經成為容器協調的首選平臺。而隨著這一趨勢,威脅和新的攻擊方式也越來越多,有必要加強所有的安全層。 在Kubernetes中,安全問題有兩個方面:集群安全和應用安全。我們已經在另一篇文章中介紹了集群安全。在這篇文章中,我們將探討如何確保Kubernetes部署和一般
    VSole
    網絡安全專家
      亚洲 欧美 自拍 唯美 另类