CKS環(huán)境搭建和題庫

test

1.創(chuàng)建 Secret

環(huán)境準備：

kubectl create namespace istio-system
kubectl create secret generic test-app --namespace istio-system --from-literal=username=test --from-literal=password=123456

參考資料：
三個網址都要看

您必須在以下 cluster /節(jié)點上完成此考題

Cluster Master 節(jié)點 工作節(jié)點
KSMV00201 ksmv00201-master ksmv00201-worker1

您可以使用以下命令來切換 cluster / 配置環(huán)境:
[candidate@cli] $ kubectl config use-context KSMV00201

Task
在namespace istio-system 中獲取名為 test-app 的現(xiàn)有 secret 的內容窟坐。

將 username 字段存儲在名為 /home/candidate/user.txt 的文件中牍鞠，
并將password 字段存儲在名為 /home/candidate/password.txt 的文件中。

您必須創(chuàng)建以上兩個文件; 它們還不存在

==不要在以下步驟中使用/修改先前創(chuàng)建的文件易迹，如果需要創(chuàng)建新的臨時文件寞缝。==

在 istio-system namespace 中創(chuàng)建一個名為 test-workflow 的新 secret，
內容如下:

username: dev-database
password: aV7HR7nU3JLx

最后涂召，創(chuàng)建一個新的 Pod，它可以通過卷訪問 secret test-workflow :

Pod名 test-secret-pod
Namespace istio-system
容器名 dev-container
鏡像 nginx
卷名 secret-volume
掛載路徑 /etc/secret

答題步驟：

1 將 test-app 的 username 和 password误澳，通過 base64 解碼保存到題目指定文件：
#方法 1：
root@cka-master01:~# kubectl get secrets test-app -n istio-system -o jsonpath={.data}
{"password":"MTIzNDU2","username":"dGVzdA=="}r
mkdir /home/candidate/ -pv
echo 'dGVzdA=='|base64 -d > /home/candidate/user.txt 
echo 'MTIzNDU2'|base64 -d > /home/candidate/password.txt

#方法 2：
mkdir /home/candidate/ -pv
kubectl get secrets -n istio-system test-app -o jsonpath={.data.username} | base64 -d > /home/candidate/user.txt 
kubectl get secrets -n istio-system test-app -o jsonpath={.data.password} | base64 -d > /home/candidate/password.txt
#檢查
cat /cks/sec/user.txt
cat /cks/sec/pass.txt

2 創(chuàng)建名為 db2-test 的 secret 使用題目要求的用戶名和密碼作為鍵值耻矮。注意要加命名空間。
#注意忆谓，如果密碼中有特殊字符（例如：$裆装，\，*倡缠，= 和 !）哨免，需要加單引號來轉義--from-literal=password='G!Y\*d$zDsb'這樣。
kubectl create secret generic test-workflow -n istio-system --from-literal=username=dev-database --from-literal=password=aV7HR7nU3JLx
#檢查
root@cka-master01:~# kubectl get secret -n istio-system test-workflow
NAME            TYPE     DATA   AGE
test-workflow   Opaque   2      25s


3 根據(jù)題目要求毡琉，參考官網铁瞒，創(chuàng)建 Pod 使用該 secret
vim k8s-secret.yaml
#添加如下內容
apiVersion: v1
kind: Pod
metadata:
 name: test-secret-pod #pod 名字
 namespace: istio-system #命名空間
spec:
  containers:
  - name: dev-container #容器名字
    image: nginx #鏡像名字
    volumeMounts: #掛載路徑
    - name: secret-volume #卷名
      mountPath: /etc/secret #掛載路徑
  volumes:
  - name: secret-volume #卷名
    secret:
      secretName: test-workflow #名為 test-workflow 的 secret

#創(chuàng)建
kubectl apply -f k8s-secret.yaml
#檢查
root@cka-master01:~# kubectl get pod -n istio-system
NAME              READY   STATUS    RESTARTS   AGE
test-secret-pod   1/1     Running   0          4s
2.ImagePolicyWebhook （準入控制器）容器鏡像掃描

環(huán)境準備：

mkdir /etc/kubernetes/controlconf -pv
cd /etc/kubernetes/controlconf

wget https://github.com/cloudflare/cfssl/releases/download/v1.6.0/cfssl_1.6.0_linux_amd64
wget https://github.com/cloudflare/cfssl/releases/download/v1.6.0/cfssljson_1.6.0_linux_amd64
chmod +x cfssl* 
mv cfssl_1.6.0_linux_amd64 /usr/local/bin/cfssl
mv cfssljson_1.6.0_linux_amd64 /usr/local/bin/cfssljson

cat << EOF | cfssl  genkey - | cfssljson -bare server
{
  "hosts": [
    "acme.local",
    "acme.local.svc.cluster.local",
    "acme.local.pod.cluster.local",
    "172.22.136.223",
    "10.244.1.0/24"
  ],
  "CN": "system:node:acme.local.pod.cluster.local",
  "key": {
    "algo": "ecdsa",
    "size": 256
  },
  "names": [
    {
      "O": "system:nodes"
    }
  ]
}
EOF

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: acme.local
spec:
  request: $(cat server.csr | base64 | tr -d '\n')
  signerName: kubernetes.io/kubelet-serving
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF

kubectl get csr|grep 'Pending'| awk 'NR>0{print $1}' |xargs kubectl certificate approve
kubectl get csr acme.local -o jsonpath='{.status.certificate}' | base64 --decode > server.crt

kubectl create namespace local

kubectl create secret tls tls-acme --key /etc/kubernetes/controlconf/server-key.pem --cert /etc/kubernetes/controlconf/server.crt --namespace local

cat << EOF > /etc/kubernetes/controlconf/image-bouncer-webhook.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: acme
  name: acme
  namespace: local
spec:
  ports:
    - name: https
      port: 8082
      targetPort: 1323
      protocol: "TCP"
  selector:
    app: acme
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: acme
  namespace: local
spec:
  selector:
    matchLabels:
      app: acme
  template:
    metadata:
      labels:
        app: acme
    spec:
      containers:
        - name: image-bouncer-webhook
          imagePullPolicy: Always
          image: "kainlite/kube-image-bouncer:latest"
          args:
            - "--cert=/etc/admission-controller/tls/tls.crt"
            - "--key=/etc/admission-controller/tls/tls.key"
            - "--debug"
          volumeMounts:
            - name: tls
              mountPath: /etc/admission-controller/tls
      volumes:
        - name: tls
          secret:
            secretName: tls-acme     # Webhook 證書的 tls 密鑰 和密鑰
EOF
kubectl apply -f /etc/kubernetes/controlconf/image-bouncer-webhook.yaml


echo $(kubectl get service -n local acme -o jsonpath='{.spec.clusterIP}') acme.local >> /etc/hosts


cat << EOF >> /etc/kubernetes/controlconf/kubeconfig.yml
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/controlconf/server.crt
    server: server
  name: bouncer_webhook
contexts:
- context:
    cluster: bouncer_webhook
    user: api-server
  name: bouncer_validator
current-context: bouncer_validator
preferences: {}
users:
- name: api-server
  user:
    client-certificate: /etc/kubernetes/pki/apiserver.crt
    client-key:  /etc/kubernetes/pki/apiserver.key
EOF

cat << EOF >> /etc/kubernetes/controlconf/admission_configuration.json 
{
  "imagePolicy": {
     "kubeConfigFile": "/etc/kubernetes/controlconf/kubeconfig.yml",
     "allowTTL": 50,
     "denyTTL": 50,
     "retryBackoff": 500,
     "defaultAllow": true
  }
}
EOF

mkdir /root/KSSC00202
cat << EOF >> /root/KSSC00202/configuration-test.yml
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-latest
spec:
  replicas: 1
  selector:
    app: nginx-latest
  template:
    metadata:
      name: nginx-latest
      labels:
        app: nginx-latest
    spec:
      containers:
      - name: nginx-latest
        image: nginx    # 不寫標簽默認是nginx:latest
        ports:
        - containerPort: 80
EOF

參考資料： 三個網址都要看

您必須在以下 cluster群 彪啊傍佬嫡尺節(jié)點上完成此考題:
Cluster Master 節(jié)點 工作節(jié)點
KSSC00202 kssc00202-master kssc00202-worker1

您可以使用以下命今來切換 cluster /配置環(huán)境
[candidate@cli] $ kubectl config use-context KSSCO0202

Context
cluster 上設置了容器鏡像掃描器，但尚未完全集成到 cluster 的配置中桅滋。完成后慧耍，容器鏡像掃描器應掃描并拒絕易受攻擊的鏡像的使用。

Task

您必須在 cluster的 master 節(jié)點上完成整個考題丐谋，所有服務和文件都已被準備好并放置在該節(jié)點上芍碧。

給定一個目錄 /etc/kubernetes/controlconf 中不完整的配置以及具有HTTPS 端點 https://acme.local:8082/image_policy
的功能性容器鏡像掃描器：

  1. 啟用必要的插件來創(chuàng)建鏡像策略
  2. 校驗控制配置并將其更改為隱式拒絕(implicit deny)
  3. 編輯配置以正確指向提供的 HTTPS 端點

最后，通過嘗試部署易受攻擊的資源
/root/KSSC00202/configuration-test.yml 來測試配置是否有效

==您可以在 /var/log/imagepolicy/wakanda.log 找到容器鏡像掃描儀的日志文件号俐。==

答題步驟：

本題分數(shù)比較多泌豆，占 10%
第 1 步 切換到 Master 的 root 下
ssh master01
sudo -i

第 2 步，編輯 admission_configuration.json（題目會給這個目錄）吏饿，修改 defaultAllow 為 false：
vi /etc/kubernetes/controlconf/admission_configuration.json
……
 "denyTTL": 50,
 "retryBackoff": 500,
 "defaultAllow": false #將 true 改為 false
……

第 3 步踪危，編輯/etc/kubernetes/controlconf/kubeconfig.yml，添加 webhook server 地址：
#操作前猪落，先備份配置文件
mkdir backup
cp /etc/kubernetes/controlconf/kubeconfig.yaml backup/
vi /etc/kubernetes/controlconf/kubeconfig.yaml
#修改如下內容
……
   certificate-authority: /etc/kubernetes/controlconf/ca.crt
   server: https://acme.local:8082/image_policy #添加 webhook server 地址
 name: image-checker
……

第 4 步贞远，編輯 kube-apiserver.yaml，從官網中引用 ImagePolicyWebhook 的配置信息：
#操作前笨忌，先備份配置文件
mkdir backup
cp /etc/kubernetes/manifests/kube-apiserver.yaml backup/
vi /etc/kubernetes/manifests/kube-apiserver.yaml
#在- command:下添加如下內容蓝仲，注意空格要對齊
 - --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
 - --admission-control-config-file=/etc/kubernetes/controlconf/admission_configuration.json #在 1.23 的考試中，默認這行已經添加了官疲，但為了以防萬一袱结，模擬環(huán)境，沒有添加途凫，需要你手動添加垢夹。考試時颖榜，你先檢查棚饵，有的話煤裙，就不要再重復添加了掩完。重復添加反而會報錯噪漾！
# 在 kube-apiserver.yaml 的 volumeMounts 增加
 volumeMounts: #在 volumeMounts 下面增加 #注意，在 1.23 考試中且蓬，藍色的內容可能已經有了欣硼，你只需要添加綠色字體的內容《褚酰可以通過紅色字诈胜，在文件中定位凳厢。但模擬環(huán)境沒有加蔬芥，需要你全部手動添加铅碍。這樣是為了練習乃正，萬一考試中沒有准脂，你也會加占锯。但是如果考試中已添加移稳，你再添加一遍走诞，則會報錯摔笤，導致 api-server 啟不起來够滑。
 - mountPath: /etc/kubernetes/controlconf
   name: kubeconfig
   readOnly: true 
 # 在 kube-apiserver.yaml 的 volumes 增加
 volumes: #在 volumes 下面增加 #注意，在 1.23 考試中吕世，藍色的內容可能已經有了彰触，你只需要檢查確認一下是否準確∶剑可以通過紅色字况毅，在文件中定位。
#但模擬環(huán)境沒有加尔艇，需要你全部手動添加尔许。這樣是為了練習，萬一考試中沒有漓帚，你也會加母债。但是如果考試中已添加，你再添加一遍尝抖，則會報錯毡们，導致 api-server啟不起來。
 - name: kubeconfig
   hostPath:
     path: /etc/kubernetes/controlconf
     type: DirectoryOrCreate
#如果你寫的是目錄昧辽，則是 DirectoryOrCreate衙熔，如果你寫的是文件，則是 File

第 5 步搅荞，重啟 kubelet红氯。
systemctl restart kubelet
#通過嘗試部署易受攻擊的資源 /root/KSSC00202/configuration-test.yml 來測試配置是否有效
#無法創(chuàng)建 pod框咙，如下報錯，表示成功痢甘。
#因為模擬環(huán)境里的 image_policy 策略是鏡像 tag 是 latest 的不允許創(chuàng)建喇嘱。
kubectl apply -f /root/KSSC00202/configuration-test.yml

第 6 步 退回到原 ssh 終端
# 退出 root，退回到 candidate@master01
exit
# 退出 master01塞栅，退回到 candidate@node01
exit
3.網絡策略 NetworkPolicy

環(huán)境準備：

mkdir /home/candidate/KSSHO0301 -pv
cat << EOF >> /home/candidate/KSSHO0301/network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: multi-port-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 32000
          endPort: 32768
EOF

kubectl create namespace development

參考資料：

Quick Reference
文檔 NetworkPolicy者铜，Pod，Namespace

您必須在以下 cluster /節(jié)點上完成此考題

Cluster Master 節(jié)點 工作節(jié)點
KSSH00301 kssh00301-master kssh00301-worker1

您可以使用以下命今來切換 cluster /配置環(huán)境
[candidate@cli] $ kubectl config use-context KSSHO0301

Task
創(chuàng)建一個名為 pod-restriction 的 NetworkPolicy 來限制對在 namespace development 中運行的 Pod users-service 的訪問

只允許以下 Pod 連接到 Pod users-service :

  • namespace qa 中的 Pod
  • 位于任何 namespace 放椰，帶有標簽 environment: staging 的 Pod

==確保應用 NetworkPolicy 作烟。==
==你可以在 /home/candidate/KSSHO0301/network-policy.yaml 找到個模板清單文件。==

答題步驟：

1 檢查 namespace 標簽
#模擬環(huán)境已提前打好標簽了砾医，所以你只需要檢查標簽即可拿撩。但為了防止考試時，沒有給你打標簽如蚜，所以還是需要你將下面打標簽的命令記住压恒。
# 查看 qaqa 命名空間標簽（name: qaqa）
kubectl get ns --show-labels

# 查看 pod 標簽（environment: testing）
kubectl get pod -n development --show-labels

如果 Pod 或者 Namespace 沒有標簽，則需要打上標簽怖亭。
#注意：我這里將 pod users-service 的標簽打成了 environment: staging涎显，下面會有解釋，不要和題目里要求的“位于任何 namespace兴猩，帶有標簽 environment: staging 的 Pod”這句話里的標簽混淆了期吓。
# kubectl label ns qa name=qa
# kubectl label pod users-service environment=staging -n development

2 創(chuàng)建 NetworkPolicy
vi /home/candidate/KSSHO0301/network-policy.yaml
#根據(jù)官網，修改為如下內容：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pod-restriction #修改
  namespace: development #修改
spec:
  podSelector:
    matchLabels:
      environment: staging #根據(jù)題目要求的標簽修改倾芝，這個寫的是 Pod products-service 的標簽讨勤，也就是使用 kubectl get pod -n dev-team --show-labels 查出來的 pod 的標簽，這個標簽不要和題目里要求的“位于任何 namespace晨另，帶有標簽 environment: testing 的 Pod”這句話里的標簽混淆了潭千，兩個沒有關系，所以可不一樣借尿。比如你考試時查出來的 POD products-service 的標簽是 name: products刨晴，那這里的 environment: testing 就要換成 name: products。
  policyTypes:
  - Ingress #注意路翻，這里只寫 - Ingress狈癞，不要將 - Egress 也復制進來！
  ingress:
  - from: #第一個 from
    - namespaceSelector:
        matchLabels:
          name: qa #命名空間有 name: qaqa 標簽的
  - from: #第二個 from
    - namespaceSelector: {} #修改為這樣茂契，所有命名空間
       podSelector: #注意蝶桶，這個 podSelector 前面的“-” 要刪除，換成空格掉冶，空格對齊要對真竖。
         matchLabels:
           environment: staging #有 environment: testing 標簽的 Pod脐雪，這個地方是根據(jù)題目要求“Pods with label environment: testing , in any namespace”，這句話里的 pod 標簽寫的恢共。不要和上面 spec 里的混淆战秋。

#創(chuàng)建
kubectl apply -f /home/candidate/KSSHO0301/network-policy.yaml
#檢查
kubectl get networkpolicy -n dev-team
4.沙箱運行容器 gVisor

環(huán)境準備：

mkdir /home/candidate/KSMV00301 -pv
cat << EOF > /home/candidate/KSMV00301/runtime-class.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: myclass
handler: mycofiguration
EOF

kubectl create namespace client
kubectl create deployment busybox-run --image nginx --namespace client 
kubectl create deployment nginx-host --image nginx --namespace client 
kubectl create deployment run-test --image nginx --namespace client

參考資料：

Quick Reference
文檔 RuntimeClass，Pod旁振，Namespace

您必須在以下 cluster /節(jié)點上完成此考題
Cluster Master 節(jié)點 工作節(jié)點
KSMV00301 ksmv00301-master ksmv00301-worker1

您可以使用以下命令來切換 cluster / 配置環(huán)境:
[candidate@cli] $ kubectl config use-context KSMV00301

Context
該 cluster 使用 containerd 作為 CRI運行時获询。containerd的默認運行時處理程序是 runc涨岁。containerd 已準備好支持額外的運行時處理程序 runsc ( gVisor ) 拐袜。

Task
使用名為 runsc 的現(xiàn)有運行時處理程序，創(chuàng)建一個名為 untrusted 的RuntimeClass .

更新 namespace client 中的所有 Pod 以在gVisor 上運行

==你可以在 /home/candidate/KSMV00301/runtime-class.yaml找到一個模板清單文件梢薪。==

答題步驟：

1 創(chuàng)建 RuntimeClass
vi /home/candidate/KSMV00301/runtime-class.yaml
#修改如下內容
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: untrusted  # 用來引用 RuntimeClass 的名字蹬铺，RuntimeClass 是一個集群層面的資源
handler: runsc  # 對應的 CRI 配置的名稱

#創(chuàng)建
kubectl apply -f /home/candidate/KSMV00301/runtime-class.yaml
#檢查
root@cka-master01:~# kubectl get runtimeclasses.node.k8s.io
NAME        HANDLER   AGE
untrusted   runsc     8s


2 將命名空間為 client 下的 Pod 引用 RuntimeClass。
#考試時秉撇，3 個 Deployment 下有 3 個 Pod甜攀，修改 3 個 deployment 即可。
kubectl -n client get deployment

#編輯 deployment
kubectl -n client edit deployments busybox-run
kubectl -n client edit deployments nginx-host
kubectl -n client edit deployments run-test
#修改如下內容
 spec: #找到這個 spec琐馆，注意在 deployment 里是有兩個單獨行的 spec 的规阀，要找第二個，也就是下面有 containers 這個字段的 spec瘦麸。
   runtimeClassName: untrusted #添加這一行谁撼，注意空格對齊，保存會報錯滋饲，忽略即可厉碟。
   containers:
   - image: nginx:1.9
     imagePullPolicy: IfNotPresent
     name: run-test
 
#因為模擬環(huán)境沒有安裝 runsc 運行環(huán)境，所以改完后屠缭，新 Pod 是ContainerCreating 狀態(tài)箍鼓。考試時呵曹，改完后 Pod 會重建并 Running 的
5.Pod指定ServiceAccount

準備環(huán)境：

mkdir /home/candidate/KSCHO0301/ -pv
kubectl create namespace dev
kubectl create serviceaccount test01 --namespace dev

cat << EOF >> /home/candidate/KSCH00301/pod-manifest.yaml
apiVersion: v1
kind: Pod
metadata:
  name: backend
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - name: nginx
      targetPort: 80
EOF
Quick Reference
文檔 ServiceAccount款咖，Pod，Namespace

您必須在以下 cluster /節(jié)點上完成此考題：
Cluster Master 節(jié)點 工作節(jié)點
KSCH00301 ksch00301-master ksch00301-worker1

您可以使用以下命今來切換 cluster / 配置環(huán)境：
[candidate@cli] $ kubectl config use-context KSCHO0301

Context
您組織的安全策略包括:

  • ServiceAccount 不得自動掛載API 憑據(jù)
  • ServiceAccount 名稱必須以“-sa”結尾

清單文件 /home/candidate/KSCHO0301/pod-manifest.yaml中指定的 Pod由于 ServiceAccount 指定錯誤而無法調度奄喂。

請完成以下項目:

Task
在現(xiàn)有 namespace dev 中創(chuàng)建一個名為 database-sa 的新ServiceAccount 確保此 ServiceAccount 不自動掛載 API 憑據(jù)

使用 /home/candidate/KSCH00301/pod-manifest.yaml 中的清單文件來創(chuàng)建一個Pod铐殃。

最后，清理 namespace dev中任何未使用的 ServiceAccount砍聊。

題目操作：

1 創(chuàng)建 ServiceAccount
vi dev-ns.yaml
根據(jù)官網修改如下內容
apiVersion: v1
kind: ServiceAccount
metadata:
  name: database-sa #修改 name
  namespace: dev #注意添加 namespace
automountServiceAccountToken: false #修改為 false背稼，表示不自動掛載 secret


kubectl apply -f dev-ns.yaml
kubectl get sa -n dev


2 創(chuàng)建 Pod 使用該 ServiceAccount
vi /home/candidate/KSCH00301/pod-manifest.yaml修改如下內容
……
metadata:
  name: backend
  namespace: dev #注意命名空間是否對
spec:
  serviceAccountName: backend-sa # 沒有則添加一行，有則修改這一行為剛才創(chuàng)建的 ServiceAccount（考試時玻蝌，默認已有這一行蟹肘，需要修改词疼。）
  containers:
……

kubectl apply -f /home/candidate/KSCH00301/pod-manifest.yaml
kubectl get pod -n dev


3. 刪除沒有使用的 ServiceAccount
查看所有 sa
kubectl get sa -n dev
查看已經在用的 sa
kubectl get pod -n dev -o yaml | grep -i serviceAccountName
刪除不用的 sa
kubectl delete sa test01 -n dev
6.日志審計 log audit

環(huán)境準備：

mkdir /etc/kubernetes/logpolicy -p
cat << EOF >> /etc/kubernetes/logpolicy/audit-policy.yaml
apiVersion: audit.k8s.io/v1 # 這是必填項。
kind: Policy
# 不要在 RequestReceived 階段為任何請求生成審計事件帘腹。
omitStages:
  - "RequestReceived"
rules:
  # 在日志中用 RequestResponse 級別記錄 Pod 變化贰盗。
  - level: RequestResponse
    resources:
    - group: ""
      # 資源 "pods" 不匹配對任何 Pod 子資源的請求，
      # 這與 RBAC 策略一致阳欲。
      resources: ["pods"]
  # 在日志中按 Metadata 級別記錄 "pods/log"舵盈、"pods/status" 請求
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # 不要在日志中記錄對名為 "controller-leader" 的 configmap 的請求。
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # 不要在日志中記錄由 "system:kube-proxy" 發(fā)出的對端點或服務的監(jiān)測請求球化。
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # core API 組
      resources: ["endpoints", "services"]

  # 不要在日志中記錄對某些非資源 URL 路徑的已認證請求秽晚。
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # 通配符匹配。
    - "/version"

  # 在日志中記錄 kube-system 中 configmap 變更的請求消息體筒愚。
  - level: Request
    resources:
    - group: "" # core API 組
      resources: ["configmaps"]
    # 這個規(guī)則僅適用于 "kube-system" 名字空間中的資源赴蝇。
    # 空字符串 "" 可用于選擇非名字空間作用域的資源。
    namespaces: ["kube-system"]

  # 在日志中用 Metadata 級別記錄所有其他名字空間中的 configmap 和 secret 變更巢掺。
  - level: Metadata
    resources:
    - group: "" # core API 組
      resources: ["secrets", "configmaps"]

  # 在日志中以 Request 級別記錄所有其他 core 和 extensions 組中的資源操作句伶。
  - level: Request
    resources:
    - group: "" # core API 組
    - group: "extensions" # 不應包括在內的組版本。

  # 一個抓取所有的規(guī)則陆淀，將在日志中以 Metadata 級別記錄所有其他請求考余。
  - level: Metadata
    # 符合此規(guī)則的 watch 等長時間運行的請求將不會
    # 在 RequestReceived 階段生成審計事件。
    omitStages:
      - "RequestReceived"
EOF

參考文檔：

您必須在以下 cluster /節(jié)點上完成此考題
Cluster Master 節(jié)點 工作節(jié)點
KSRS00602 ksrs00602-master ksrs00602-worker1

您可以使用以下命今來切換 cluster /配置環(huán)境:
[candidate@cli] $ kubectl config use-context KSRS00602

Task
在 cluster 中啟用審計日志轧苫。為此楚堤，請啟用日志后端，并確保：

  • 日志存儲在 /var/log/kubernetes/logs.txt
  • 日志文件能保留 10 天
  • 最多保留 1個日審計日志文件

/etc/kubernetes/logpolicy/audit-policy.yaml 提供了基本策略浸剩。
它僅指定不記錄的內容钾军。

==基本策略位于 cluster的 master 節(jié)點上==

編輯和擴展基本策略以記錄：

  • RequestResponse 級別的 cronjobs 更改
  • namespace frontweb 中 deployments 更改的請求體
  • Metadata 級別的所有 namespace 中的 ConfigMap 和 Secret 的更改

此外，添加一個全方位的規(guī)則以在 Metadata 級別記錄所有其他請求

==不要忘記應用修改后的策略==

答題步驟：

#本題分數(shù)比較多绢要，占 12%吏恭。
#日志審計這一題需要自己調整的內容還是挺多的，因此要非常仔細重罪，建議修改前備份一下原始的環(huán)境樱哼，要不然修改錯了就會導致集群崩潰。
#1 切換到 Master 的 root 下
ssh master01
sudo -i

#2.配置審計策略
#先備份配置文件
mkdir backup
cp /etc/kubernetes/logpolicy/audit-policy.yaml backup/
vim /etc/kubernetes/logpolicy/audit-policy.yaml

#參考官方網址內容
……rules:
# namespaces changes at RequestResponse level
- level: RequestResponse
    resources:
    - group: ""
        resources: ["cronjobs"] #根據(jù)題目要求修改剿配，比如題目要求的是 namespaces或者persistentvolumes搅幅。
#the request body of persistentvolumes/pods changes in the namespace front-apps
- level: Request
    resources:
    - group: ""
        resources: ["deployments"] #根據(jù)題目要求修改，比如題目要求的是 configmaps 或者 persistentvolumes 或者 pods呼胚。
    namespaces: ["frontweb"]
# Log configmap and secret changes in all other namespaces at the Metadata level.
- level: Metadata
    resources:
    - group: ""
        resources: ["secrets", "configmaps"]
# Also, add a catch-all rule to log all other requests at the Metadata level.
- level: Metadata
    omitStages:
    - "RequestReceived"


#3 配置 master 節(jié)點的 kube-apiserver.yaml
#先備份配置文件
mkdir backup
cp /etc/kubernetes/manifests/kube-apiserver.yaml backup/
vi /etc/kubernetes/manifest
# 添加以下參數(shù)茄唐，注意空格要對齊，注意檢查，如果考試中已經存在了則不要重復添加沪编。
  - command:
    - --audit-policy-file=/etc/kubernetes/logpolicy/audit-policy.yaml #定義審計策略yaml文件位置呼盆，通過 hostpath 掛載
    - --audit-log-path=/var/log/kubernetes/logs.txt                   #定義審計日志位置，通過 hostpath 掛載
    - --audit-log-maxage=10                                           #定義保留舊審計日志文件的最大天數(shù)為 10 天
    - --audit-log-maxbackup=1                                         #定義要保留的審計日志文件的最大數(shù)量為 1 個


    volumeMounts:               #找到這個字段蚁廓，添加下面內容
    - mountPath: /etc/kubernetes/logpolicy/audit-policy.yaml    #這里也可以寫到目錄/etc/kubernetes/logpolicy/
      name: audit
      readOnly: true    #這個為 true
    - mountPath: /var/log/kubernetes/
      name: audit-logs
      readOnly: false   #這個為 false

  volumes:                  #找到這個字段访圃，添加下面內容
  - hostPath:
      path: /etc/kubernetes/logpolicy/audit-policy.yaml
      type: File            #file如果寫到目錄/etc/kubernetes/logpolicy/，則type:應為 type: DirectoryOrCreate
    name: audit
  - hostPath:
      path: /var/log/kubernetes/
      type: DirectoryOrCreate
    name: audit-logs

#4 重啟 kubelet 服務
systemctl restart kubelet

等待 2 分鐘后相嵌，再檢查
kubectl get pod -A
tail /var/log/kubernetes/logs.txt

# 退出 root腿时，退回到 candidate@master01
exit
# 退出 master01，退回到 candidate@node01
exit
7.AppArmor（限制容器對資源的訪問）

環(huán)境準備：

cat << EOF >>/etc/apparmor.d/nginx_apparmor
#include <tunables/global>
nginx-profile-3  
profile nginx-profile-3 flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # 拒絕所有文件寫入
  deny /** w,
}
EOF

mkdir /home/candidate/KSSH00401 -pv
cat << EOF >> /home/candidate/KSSH00401/nginx-ds.yaml
apiVersion: v1
kind: Pod
metadata:
  name: podx
spec:
  containers:
  - image: busybox
    imagePullPolicy: IfNotPresent
    name: podx 
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
    resources: {}
  nodeName: node01
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}
EOF

參考資料：

Quick Reference
文檔 AppArmor饭宾，Pod批糟，Node

您必須在以下 cluster /節(jié)點上完成此考題:
Cluster Master 節(jié)點 工作節(jié)點
KSSH00401 kssh00401-master kssh00401-worker1

您可以使用以下命令來切換 cluster /配置環(huán)境:
[candidate@cli] $ kubectl config use-context KSSHO0401

Context
AppArmor 已在 cluster 的工作節(jié)點上被啟用。一個AppArmor 配置文件已存在捏雌，但尚未被實施跃赚。

==您可以使用瀏覽器打開一個額外的標簽頁來訪問 AppArmor 的文檔==

Task
在cluster 的工作節(jié)點上，實施位于 /etc/apparmor.d/nginx_apparmor 的現(xiàn)有AppArmor 配置文件

編輯位于 /home/candidate/KSSH00401/nginx-ds.yaml 的現(xiàn)有清單文件以應用AppArmor 配置文件性湿。

最后，應用清單文件并創(chuàng)建其中指定的 Pod满败。

答題步驟：

1 切換到 node02 的 root 下
ssh node02
sudo -i

2 切換到 apparmor 的目錄肤频，并檢查配置文件
cd /etc/apparmor.d/
#在考試時，可以先 cat /etc/apparmor.d/nginx_apparmor算墨，有錯誤則改宵荒，沒錯誤，則不要再改了
cat /etc/apparmor.d/nginx_apparmor
#include <tunables/global>

# nginx-profile-3 #注釋掉 模擬環(huán)境里多寫了一行的净嘀，會導致 apparmor_parser -q 的時候會報錯报咳。

profile nginx-profile-3 flags=(attach_disconnected) { 
#這句是正確的配置，不要修改挖藏。profile 后面的 nginx-profile-3 為 apparmor 策略模塊的名字暑刃。

  file,

  # 拒絕所有文件寫入
  deny /** w,
}


3 執(zhí)行 apparmor 策略模塊
#沒有 grep 到，說明沒有啟動膜眠。
apparmor_status | grep nginx-profile-3
#加載啟用這個配置文件
apparmor_parser -q /etc/apparmor.d/nginx_apparmor
# 再次檢查有結果了
root@cka-master1:~# apparmor_status | grep nginx
   nginx-profile-3


4 修改 pod 文件
vi /home/candidate/KSSH00401/nginx-ds.yaml
#修改如下內容
……
metadata:
  name: podx
  annotations:
    container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3
    #添加 annotations岩臣，kubernetes.io/podx 名字和 containers 下的名字一樣即可，nginx-profile-3 為前面在 worker node01 上執(zhí)行的 apparmor 策略模塊的名字宵膨。
spec:
  containers:
  - image: busybox
    imagePullPolicy: IfNotPresent
    name: podx #這個就是 containers 下的名字架谎，為 podx
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
……

#創(chuàng)建
kubectl apply -f /cks/KSSH00401/nginx-deploy.yaml

# 退出 root，退回到 candidate@node02
exit
# 退出 node02辟躏，退回到 candidate@node01
exit
8.Trivy 掃描鏡像安全漏洞

環(huán)境準備：

https://github.com/aquasecurity/trivy
wget https://github.com/aquasecurity/trivy/releases/download/v0.48.2/trivy_0.48.2_Linux-64bit.tar.gz
tar -zxf trivy_0.48.2_Linux-64bit.tar.gz
mv trivy /usr/local/bin/

kubectl create namespace naboo

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: tri222
  namespace: naboo
spec: 
  containers:
  - name: amazonlinux
    image: amazonlinux:1
  - name: nginx
    image: nginx:1.19
EOF
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: tri333
  namespace: naboo
spec: 
  containers:
  - name: amazonlinux
    image: amazonlinux:2
  - name: vicuu-nginx
    image: vicuu/nginx:host
EOF

參考資料：

Quick Reference
文檔 Trivy

您必須在以下 cluster /節(jié)點上完成此考題
Cluster Master 節(jié)點 工作節(jié)點
KSSC00401 kssc00401-master kssc00401-worker1

您可以使用以下命今來切換 cluster /配置環(huán)境
[candidate@cli] $ kubectl config use-context KSSCO0401

==您可以使用瀏覽器打開一個額外的標簽頁來訪問 Trivy 的文檔==

Task
使用 Trivy 開源容器掃描器檢測 namespace naboo 中 Pod 使用的具有嚴重漏洞的鏡像

查找具有 High 或 Critical 嚴重性漏洞的鏡像谷扣，并刪除使用這些鏡像的 Pod

==Trivy 僅預裝在 cluster 的 master 節(jié)點上; 它在原本的系統(tǒng)或工作節(jié)點上不可用。您必須連接到 cluster 的 master 節(jié)點才能使用 Trivy捎琐。==

答題步驟：

注意：這個題非常耗費時間会涎，考試時關注一下剩余時間涯曲。如果時間剩余不多，可以放到最后做這道題在塔。
方法 1：（推薦幻件，能快一些）
1 切換到 Master 的 candidate 下
ssh master01

2 獲取命名空間 naboo 下的所有 pod 的 image
kubectl get pods --namespace naboo --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"

3 檢查鏡像是否有高危和嚴重的漏洞
trivy image -s HIGH,CRITICAL nginx:1.19 # HIGH,CRITICAL，這里的 nginx:1.19 換成你上一步查出來的鏡像名字
# 或者也可以使用這條命令查詢 trivy image nginx:1.19 | grep -iE 'High|Critical'
# 注意 tri222 和 tri333 的 2 個 pod 里各有 2 個 image蛔溃，都需要掃描绰沥。
trivy image -s HIGH,CRITICAL amazonlinux:1
trivy image -s HIGH,CRITICAL amazonlinux:2
trivy image -s HIGH,CRITICAL nginx:1.19
trivy image -s HIGH,CRITICAL vicuu/nginx:host

4 刪除有問題的 pod
kubectl delete pod XXXX -n kamino
5 退出 master01，退回到 candidate@node01
exit
#請注意贺待，考試時有 5 個 pod徽曲，每個 pod 里有多個 image 鏡像，都需要掃描麸塞。掃描出有漏洞的鏡像秃臣，則刪除有這個鏡像的 pod。
#另外哪工，網友 WilliamLee 還提供了一種方法奥此，對 shell 命令比較熟習的，可以參考雁比。
#讓它后臺掃稚虎，然后退出來繼續(xù)做其他的，做完其他的回來看報告偎捎，刪 pod蠢终。
#注意別忘了每道題要切換集群。


方法 2：（太消耗時間茴她，因為考試時寻拂，有 5 個 pod，而且每一個 pod 里面還有兩三個 image）
# 切換到 Master 的 root 下
ssh master01
#檢查所有 pod
kubectl get pod -n naboo
#獲取每一個 pod 的 image
kubect get pod XXXX -n naboo -o yaml | grep image
#檢查鏡像是否有高危和嚴重的漏洞
trivy image -s HIGH,CRITICAL nginx:1.19 # HIGH,CRITICAL丈牢，這里的 nginx:1.19 換成你上一步查出來的鏡像名字
#或者也可以使用下面命令查詢: trivy image nginx:1.19 | grep -iE 'High|Critical'
# 刪除有問題的 pod
kubectl delete pod XXXX -n naboo
# 退出 master01祭钉，退回到 candidate@node01
exit
#請注意，考試時有 5 個 pod赡麦，每個 pod 里有多個 image 鏡像朴皆。檢查出有漏洞的鏡像，則刪除有這個鏡像的 pod泛粹。


方法 3：（寫 while 腳本有點麻煩）
（對于 pod 數(shù)量多的情況遂铡，可以使用下面方法）
# 切換到 Master 的 root 下
ssh master01
檢查所有 pod
kubectl get po -n naboo
kubectl get po -n naboo | grep -v "NAME" | awk '{print $1}' > podlist.txt
cat podlist.txt
#循環(huán)檢查 pod 里的 image
while read line;do
echo $line
kubectl get pod -n naboo $line -o yaml | grep "image:"
done < podlist.txt
#對查出來的 image 逐一掃描
trivy image -s HIGH,CRITICAL nginx:1.19 #注意 HIGH,CRITICAL 為大寫
#刪除掃描的鏡像帶有高危或嚴重漏洞的 Pod
kubectl delete pod XXXX -n kamino

# 退出 master01晶姊，退回到 candidate@node01
exit
9.容器安全扒接，更改特權 Pod

準備環(huán)境：

mkdir /home/candidate/finer-sunbeam/ -pv
kubectl create namespace lamp
cat << EOF > /home/candidate/finer-sunbeam/lamp-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: lamp-deployment
  namespace: lamp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: lamp
  template:
    metadata:
      labels:
        app: lamp
    spec:
      containers:
      - name: lamp-container
        image: nginx
        securityContext:
          readOnlyRootFilesystem: false
          allowPrivilegeEscalation: true
EOF
kubectl apply -f /home/candidate/finer-sunbeam/lamp-deployment.yaml
Quick Reference
文檔 Deployment，Pod，Namespace

您必須在以下 cluster /節(jié)點上完成此考題:
Cluster 控制平面節(jié)點 工作節(jié)點
KSRS00502 ksrs00502-master ksrs00502-worker1

您可以使用以下命令來切換 cluster /配置環(huán)境:
[candidate@cli] $ kubectl config use-context KSRS00502

Context
必須更新一個現(xiàn)有的Pod 以確保其容器 的不變性

Task
修改運行在namespace lamp钾怔，名為 lamp-deployment 的現(xiàn)有 Deployment使其容器 :

  • 使用用戶ID 10000 運行
  • 使用一個只讀的根文件系統(tǒng)
  • 禁止特權提升

??您可以在 /home/candidate/finer-sunbeam/lamp-deployment.yaml 找到lamp-deployment 的清單文件

答題步驟：


apiVersion: apps/v1
kind: Deployment
metadata:
  name: lamp-deployment
  namespace: lamp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: lamp
  template:
    metadata:
      labels:
        app: lamp
    spec:
      securityContext:
        runAsUser: 10000
      containers:
      - name: lamp-container
        image: nginx
        securityContext:
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
10.默認網絡策略
Quick Reference
文檔 NetworkPolicy碱呼，Pod，Namespace

您必須在以下 cluster /節(jié)點上完成此考題:
Cluster Master 節(jié)點 工作節(jié)點
KSCS00101 kscs00101-master kscs00101-worker1

您可以使用以下命今來切換 cluster /配置環(huán)境
[candidate@cli] $ kubectl config use-context KSCS00101

Context
一個默認拒絕 (default-deny) 的 NetworkPolicy 可避免在未定義任何其他NetworkPolicy的namespace 中意外公開 Pod宗侦。

Task
為所有類型為 Ingress + Egress 的流量在 namespace development 中創(chuàng)建一個名為 denypolicy 的新默認拒絕 NetworkPolicy愚臀。

此新的 NetworkPolicy 必須拒絕 namespace development 中的所有Ingress + Egress 流量
將新創(chuàng)建的默認拒絕 NetworkPolicy 應用于在 namespace development 中運行的所有 Pod 。

==你可以在 /home/candidate/KSCS00101/network-policy.yaml 找到一個模板清單文件矾利。==

準備環(huán)境：

mkdir -pv /home/candidate/KSCS00101
vim /home/candidate/KSCS00101/network-policy.yaml
kubectl create namespace development

考題操作：

#創(chuàng)建名為 denypolicy 的 NetworkPolicy姑裂，拒絕 testing 命名空間內所有 Ingress + Egress 流量
#（這里可能是 ingress 或 egress 或 ingress+egress，根據(jù)題目要求寫男旗。）
vi /home/candidate/KSCS00101/network-policy.yaml
#修改為
……
metadata:
name: denypolicy #修改 name
namespace: development #注意添加 namespace
spec:
podSelector: {}
policyTypes:
- Ingress #注意看題舶斧，是 Ingress + Egress（入口+出口），還是只是 Ingress 或只是 Egress察皇。
- Egress #在 1.23 的考試中茴厉，只要求拒絕所有 Egress 流量，那就只寫這這個- Egress 即可什荣，這種情況就不要寫- Ingress 了矾缓。

#創(chuàng)建
kubectl apply -f /home/candidate/KSCS00101/network-policy.yaml
#檢查
kubectl describe networkpolicy denypolicy -n testing
11.啟用 API server 認證

環(huán)境準備：

參考資料：

Quick Reference
文檔 kubeadm ，ClusterRoleBinding溃睹，kubect

您必須在以下 cluster /節(jié)點上完成此考題
Cluster Master 節(jié)點 工作節(jié)點
KSCH00101 ksch00101-master ksch00101-worker1

您可以使用以下命今來切換 cluster /配置環(huán)境
[candidate@cli] $ kubectl config use-context KSCH00101

Context
由 kubeadm創(chuàng)建的集群的 Kubernetes API 服務器而账，出于測試目的，臨時配置為允許未經身份驗證和未經授權的訪問因篇，授予匿名用戶 cluster-admin 的訪問權限。

Task
重新配置 cluster的 Kubernetes API 服務器以確保只允許經過身份驗證和授又的 REST 請求

使用授權模式 Node,RBAC 和準入控制器 NodeRestriction.

刪除用戶 system:anonymous 的 ClusterRoleBinding 來進行清理

==所有kubectl配置環(huán)境/文件也被配置為使用未經身份驗證和未經授權的訪問笔横。==
==您不必更改它竞滓，但請注意，一旦完成 cluster 的安全加固吹缔，kubectl的配置將無法工作商佑。==

==您可以使用位于 cluster 的 master 節(jié)點上， cluster 原本的kubectl 配置文件 /etc/kubernetes/admin.conf厢塘，以確保經過身份驗證和授權的請求仍然被允許==

答題步驟：

1 切換到 Master 的 root 下
ssh master01
sudo -i

請先執(zhí)行如下命令茶没，模擬這道題的初始環(huán)境。
腳本在 master01 的/root 目錄下晚碾。
sh b.sh

2 確保只有認證并且授權過的 REST 請求才被允許
#編輯/etc/kubernetes/manifests/kube-apiserver.yaml抓半，修改下面內容
- --authorization-mode=AlwaysAllow
- --enable-admission-plugins=AlwaysAdmit
vi /etc/kubernetes/manifests/kube-apiserver.yaml
#修改為
- --authorization-mode=Node,RBAC #注意，只保留 Node,RBAC 這兩個格嘁，中間是英文狀態(tài)下的逗號笛求。在 1.23 考試中，這一條可能默認已經有
了，但還是要檢查確認一下探入。
- --enable-admission-plugins=NodeRestriction #在 1.23 考試中狡孔，這一個原先為 AlwaysAdmit，需要修改為 NodeRestriction蜂嗽。
- --client-ca-file=/etc/kubernetes/pki/ca.crt #這一條也要檢查一下苗膝，是否存在配置文件中，如果沒有植旧，也需要添加辱揭。在 1.23 考試中，這一條默認已經有了隆嗅。
- --enable-bootstrap-token-auth=true #這一條也要檢查一下界阁，是否存在配置文件中，如果沒有胖喳，也需要添加泡躯。在 1.23 考試中，這一條默認已經有了丽焊。
#網友反饋和糾正
#重啟 kubelet
systemctl daemon-reload
systemctl restart kubelet
#修改完成后较剃，等待 3 分鐘，集群才會恢復正常技健。
kubectl get pod -A

3 刪除題目要求的角色綁定
#查
kubectl get clusterrolebinding system:anonymous
#刪
kubectl delete clusterrolebinding system:anonymous
#再檢查
kubectl get clusterrolebinding system:anonymous
# 退出 root写穴，退回到 candidate@master01
exit
# 退出 master01，退回到 candidate@node01
exit
12.RBAC - RoleBinding

環(huán)境準備：

kubectl create ns db
kubectl -n db create serviceAccount test-sa-3
kubectl -n db create role role-1
kubectl -n db create role role-1 --verb=get,list,watch --resource='*'
kubectl -n db create rolebinding role-1-binding --role='role-1' --serviceaccount='db:test-sa-3'

cat << EOF > /opt/pod1.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  namespace: db
spec:
  serviceAccountName: test-sa-3
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: web-pod
EOF
    
kubectl apply -f /opt/pod1.yaml
Quick Reference
文檔 Role雌贱，RoleBinding啊送，ServiceAccount，Pod

您必須在以下 cluster /節(jié)點上完成此考題:
Cluster Master 節(jié)點 工作節(jié)點
KSCH00201 ksch00201-master ksch00201-worker1

您可以使用以下命令來切換 cluster /配置環(huán)境
candidate@cli] $ kubectl config use-context KSCHO0201

Context
綁定到 Pod 的 ServiceAccount的 Role 授予過度寬松的權限欣孤。完成以下項目以減少權限集

Task
一個名為 web-pod 的現(xiàn)有 Pod 已在namespace db中運行

編輯綁定到 Pod 的 ServiceAccount test-sa-3 的現(xiàn)有 Role馋没，僅允許只對 endpoints類型的資源執(zhí)行 watch 操作。

在namespace db 中創(chuàng)建一個名為 role-2降传，并僅允許只對 namespaces 類型的資源 執(zhí)行 update 操作的新 Role篷朵。

創(chuàng)建一個名為 role-2-binding 的新 RoleBinding，將新創(chuàng)建的 Role 綁定到 Pod 的 ServiceAccount 婆排。

==請勿刪除現(xiàn)有的 RoleBinding==

答題步驟：

#查看 ServiceAccount test-sa-3 對應的 rolebindings role-1-binding
#查看 rolebindings role-1-binding 對應的 role 為 role-1
root@cka-master01:~# kubectl describe rolebindings -n db
Name:         role-1-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  `Name:  role-1`
Subjects:
  Kind            Name                 Namespace
  ----            ----                 ---------
  `ServiceAccount  test-sa-3            db`


#編輯 role-1 權限：
kubectl edit role role-1 -n db
#修改如下內容
……
  resourceVersion: "30867"
  uid: 22e3c185-f7f5-4542-b86a-6ce153aa1c5a
rules: #模擬環(huán)境里要刪除掉 null声旺，然后添加以下內容《沃唬考試時腮猖，要根據(jù)實際情況修改。
- apiGroups: [""]
  resources: ["endpoints"] #只允許對 endpoints 資源類型執(zhí)行 watch 操作翼悴。還有可能會考只允許對 services 資源 list 的操作
  verbs: ["watch"]  # 三種權限watch,get,list

#檢查
root@cka-master01:~# kubectl describe role -n db role-1
Name:         role-1
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
 `endpoints  []                 []              [watch]`


#在 db 命名空間缚够， 創(chuàng)建名為 role-2 的 role幔妨，并且通過 rolebinding 綁定 test-sa-3，只允許對 namespaces 做 delete 操作谍椅。
#記住 --verb 是權限误堡，可能考 delete 或者 update 等 --resource 是對象，可能考 namespaces 或者 persistentvolumeclaims 等雏吭。
kubectl create role role-2 --verb=update --resource=namespaces -n db
kubectl create rolebinding role-2-binding --role=role-2 --serviceaccount=db:test-sa-3 -n db

#檢查
root@cka-master01:~# kubectl describe rolebindings -n db role-2-binding
Name:         role-2-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
 `Name:  role-2`
Subjects:
  Kind            Name       Namespace
  ----            ----       ---------
 `ServiceAccount  test-sa-3  db`
13.第14題 TLS通信加強【新題】
Quick Reference
文檔 cipher suites

您必須在以下 cluster /節(jié)點上完成此考題!
Cluster Master 節(jié)點 工作節(jié)點
KSMV00401 ksmv00401-master ksmv00401-worker1

您可以使用以下命今來切換 cluster / 配置環(huán)境
[candidate@cli] $ kubectl config use-context KSMV00401

Context
個現(xiàn)有的 Kubernetes 集群應通過更新其中一部分組件的 TLS 配置來進行加固锁施。

Task
修改API 服務器和 etcd 之間通信的 TLS 配置

對于API服務器，刪除對除 TLS 1.2 及更高版本之外的所有 TLS 版本的支持杖们。此外悉抵，刪除對除 TLS_ECDHE_ECDSA_WITH AES_128_GCM_SHA256 之外的所有密碼套件 的支持

==確保應用配置的更改==

對于etcd，刪除對除 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 之外的所有密碼套件的支持摘完。

==確保應用配置的更改姥饰。==

答題步驟：

# 修改kube-apiserver.yaml, vim /etc/kubernetes/manifests/kube-apiserver.yaml,刪除如下兩行，
    - --tls-min-version=VersionTLS13
    - --tls-cipher-suites=TLS_AES_128_GCM_SHA256
    
# 修改etcd.yaml, vim /etc/kubernetes/manifests/etcd.yaml,參考etcd命令幫助孝治，刪除如下一行列粪， 
    - --cipher-suites=TLS_AES_128_GCM_SHA256
14.Sysdig & falco

環(huán)境準備：

node:
curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash
mkdir /opt/KSR00101/incidents/ -pv

master:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec: 
  containers:
  - name: tomcat
    image: tomcat:7.0.59
EOF
Quick Reference
文檔 Falco，Deployment谈飒，Pod岂座，kubectl

您必須在以下 cluster /節(jié)點上完成此考題:
Cluster Master 節(jié)點 工作節(jié)點
KSRS00101 ksrs00101-master ksrs00101-worker1

您可以使用以下命令來切換 cluster /配置環(huán)境
[candidate@cli] $ kubectl config use-context KSRS00101

==您可以使用瀏覽器打開一個額外的標簽頁來訪問 Falco 的文檔。==

Task
使用運行時檢測工具檢測在屬于 Pod tomcat 的單個容器中頻繁產生和執(zhí)行的異常進程杭措。

cluster 的工作節(jié)點上已預裝了兩個工具:

  • sysdig
  • falco

使用您選擇的工具(包括任何非預安裝的工具)费什，分析容器的行為至少 120秒，使用過濾器檢測新生成和執(zhí)行的進程手素。

==沒有預安裝的工具是被刻意配置成可以檢測上述定義的異常進程的鸳址。==

在 /opt/KSRS00101/incidents/summary中存儲一個事件文件，其中包含檢測到的事件泉懦，每行一個氯质，格式如下:

timestamp,uid or username,processName

以下示例顯示了格式正確的事件文件

01:40:19.601363716,root,init
01:40:20.606013716,nobody,bash
01:40:21.137163716,1000,tar

==保持工具原本的時間戳格式==

==確保將事件文件存儲在 cluster 的工作節(jié)點上。==

答題步驟：

#網友的反饋祠斧，之前的考試環(huán)境的 K8S 集群使用的容器全是 docker，新考試環(huán)境拱礁，部分使用 docker琢锋，部分使用 containerd。
#這也證明了 CKS 確實有多套考試環(huán)境的呢灶。
#所以此題給出了兩個方法吴超，方法 1 是 containerd 的，方法 2 是 docker 的端铛。
#考試時乏苦，你可以先 docker ps 看一下，如果沒有這個 pod和二，則應該是使用的 containerd鸟悴。

考試形式 1 ：K8S 集群使用 containerd
1 切換到 node02 的 root 下
ssh node02
sudo -i
2陈辱、先找到 containerd 的 socket
crictl info | grep sock
3、crontainerd 要使用 crictl 命令找到容器细诸，題目要求的是 tomcat123沛贪，則 grep tomcat。
crictl ps | grep tomcat
4震贵、通過 sysdig 掃描容器 30s 并輸出到指定文件：sysdig -h 和-l 查看幫助
#注：可以使用 sysdig -l |grep time 過濾利赋，確認輸出格式字段
sysdig -l | grep time
sysdig -l | grep uid
sysdig -l | grep proc
#開始掃描 （我目前想不到別的方法，只能將命令分成 2 條了猩系，誰有更好的方法媚送，可以分享一下。）
sysdig -M 120 -p "%evt.time,%user.uid,%proc.name" --cri /run/containerd/containerd.sock container.name=tomcat >> /opt/KSR00101/incidents/summary
sysdig -M 120 -p "%evt.time,%user.name,%proc.name" --cri /run/containerd/containerd.sock container.name=tomcat >> /opt/KSR00101/incidents/summary
#提示：如果考試時執(zhí)行 sysdig 報錯“Unable to load the driver”寇甸，則執(zhí)行下面一條命令：（模擬環(huán)境里不需要執(zhí)行）
#啟用模塊
sysdig-probe-loader
#然后再次執(zhí)行 sysdig -M 30 ……
#如果還是報錯塘偎，就重裝一下 sysdig，命令為 apt install sysdig

#查看保存的文件
root@cka-node1:~# cat /opt/KSR00101/incidents/summary |head
11:25:21.238100288,root,java
11:25:21.238102819,root,java
11:25:21.238103334,root,java
11:25:21.238111198,root,java
11:25:21.238114193,root,java
11:25:21.288211283,root,java
11:25:21.288218106,root,java
11:25:21.288219427,root,java
11:25:21.288233586,root,java
11:25:21.288241225,root,java

# 退出 root幽纷，退回到 candidate@node02
exit
# 退出 node02式塌，退回到 candidate@node01
exit

考試形式 2 ：K8S 集群使用 docker（1.24 基本不考這種了）
#以下命令記住即可，模擬環(huán)境使用的是 containerd友浸。
1 切換到 node02 的 root 下
ssh node02
sudo -i
#首先找到容器的 container id：峰尝，我這里的容器 id 為 40c3c3e8b813
docker ps | grep tomcat
#通過 sysdig 掃描容器 30s 并輸出到指定文件：
sysdig -h 和-l 查看幫助
#注：可以使用 sysdig -l |grep time 過濾，確認輸出格式字段
sysdig -l | grep time
sysdig -l | grep uid
sysdig -l | grep proc

#開始掃描
sysdig -M 30 -p "%evt.time,%user.uid,%proc.name" container.id=40c3c3e8b813 > /opt/KSR00101/incidents/summary
#查看保存的文件
cat /opt/KSR00101/incidents/summary |head

# 退出 root收恢，退回到 candidate@node02
exit
# 退出 node02武学，退回到 candidate@node01
exit
15. kube-bench 修復不安全項

您必須在以下 cluster /節(jié)點上完成此考題:
Cluster Master 節(jié)點 工作節(jié)點
KSCS00201 kscs00201-master kscs00201-worker1

您可以使用以下命今來切換 cluster /配置環(huán)境
[candidate@cli] $kubectl config use-context KSCS00201

Context
針對 kubeadm 創(chuàng)建的 cluster 運行 CIS 基準測試工具時，發(fā)現(xiàn)了多個必須立即解決的問題

Task
通過配置修復所有問題并重新啟動受影響的組件以確保新設置生效伦意。

修復針對 Kubelet 發(fā)現(xiàn)的所有以下違規(guī)行為:

2.1.2 Ensure that the --anonymous-auth argument is set to false                         FAIL
2.1.3 Ensure that the --authorization-mode argument is not set to AlwaysAllow           FAIL
翻譯：
2.1.2確保anonymous-auth參數(shù)設置為false                     失敗
2.1.3確被鹬希——authorization-mode參數(shù)沒有設置為alwaysallow      失敗

==盡可能使用 Webhook身份驗證/授權==

修復針對 etcd 發(fā)現(xiàn)的所有以下違規(guī)行為：

2.2 Ensure that the --client-cert-auth argument is set to true                          FAIL
翻譯：
2.2確保——client-cert-auth參數(shù)設置為true                    失敗

環(huán)境配置：

wget https://github.com/aquasecurity/kube-bench/releases/download/v0.6.17/kube-bench_0.6.17_linux_amd64.deb
dpkg -i  kube-bench_0.6.17_linux_amd64.deb


root@cka-master1:~# sed -i 's/- --authorization-mode=Node,RBAC/#- --authorization-mode=Node,RBAC/g' /etc/kubernetes/manifests/kube-apiserver.yaml
root@cka-master1:~# cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -e "- --authorization-mode=Node,RBAC"
          #- --authorization-mode=Node,RBAC

做題操作：

# 1 切換到 Master 的 root 下
ssh master01
sudo -i

sh a.sh

# 2 修改 api-server
kube-bench master
# 查出來的驮肉，可能很多不安全項熏矿，但只修改考題要求的哪幾項就行的。

#修改之前离钝，備份一下配置文件票编。
mkdir bak1
cp /etc/kubernetes/manifests/kube-apiserver.yaml bak1/
vim /etc/kubernetes/manifests/kube-apiserver.yaml

修改、添加卵渴、刪除相關內容
#修改 authorization-mode慧域，注意 Node 和 RBAC 之間的符號是英文狀態(tài)的逗號，而不是點浪读。
- --authorization-mode=Node,RBAC
#刪除 insecure-bind-address昔榴，考試中辛藻，有可能本來就沒寫這行。
- --insecure-bind-address=0.0.0.0

# 3 修改 kubelet
kube-bench node

#修復方法 1：（推薦）
#如果考試時互订，你用方法 1 改完后吱肌， kubelet 啟動不了， 肯定是你哪里改錯了屁奏，如果又排查不出來岩榆， 則恢復此文件， 再使用方法 2 修改坟瓢。
systemctl status kubelet
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 
#中你也會看到 Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"勇边。
#所以去修改這個文件

#修改之前，備份一下配置文件折联。
mkdir bak1
cp /var/lib/kubelet/config.yaml bak1/
vim /var/lib/kubelet/config.yaml
# 修改
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous: #修改 anonymous 下的粒褒，將 true 改為 false
    enabled: false #改為 false
  webhook:
    cacheTTL: 0s
    enabled: true #這個 webhook 下的 true 不要改
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization: #修改 authorization 下的
  mode: Webhook #改為 Webhook
    webhook:
……

#編輯完后重新加載配置文件，并重啟 kubelet
systemctl daemon-reload
systemctl restart kubelet.service

修復方法 2：（不推薦诚镰， 建議用方法 1）
考試中奕坟，任選一種方法即可，模擬環(huán)境里推薦第一種方法清笨。
systemctl status kubelet
修改之前月杉，備份一下配置文件
mkdir bak1
cp /etc/systemd/system/kubelet.service.d/10-kubeadm.conf bak1/
vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
#在[Service]下面添加
Environment="KUBELET_SYSTEM_PODS_ARGS=--anonymous-auth=false"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook"
#在 ExecStart 后追加
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
$KUBELET_SYSTEM_PODS_ARGS $KUBELET_AUTHZ_ARGS
#編輯完后重新加載配置文件，并重啟 kubelet
systemctl daemon-reload
systemctl restart kubelet.service


# 4 修改 etcd
kube-bench

#修改之前抠艾，備份一下配置文件苛萎。
mkdir bak1
cp /etc/kubernetes/manifests/etcd.yaml bak1/
vim /etc/kubernetes/manifests/etcd.yaml
#修改
- --client-cert-auth=true #修改為 true

修改完成后，等待 2 分鐘检号，再檢查一下所有 pod腌歉，確保模擬環(huán)境里的所有 pod 都正常。
kubectl get pod -A

# 退出 root齐苛，退回到 candidate@master01
exit
# 退出 master01翘盖，退回到 candidate@node01
exit

做下一題之前，確保所有的 pod 都是 Running凹蜂，特別是 kube-apiserver-master01 也正常馍驯。（考試時，也要確保這個 apiserver 是正常的）
模擬環(huán)境里玛痊， calico-apiserver 和 calico-system 的幾個 pod 可能需要比較長的時間才能恢復到 Running 狀態(tài)泥彤，此時只要確保其他 pod 已恢復 Running 就可以繼續(xù)
做題了。
16.Dockerfile 檢測

環(huán)境準備：

mkdir -pv /home/candidate/KSSC00301/
cat << EOF > /home/candidate/KSSC00301/Dockerfile
FROM ubuntu:last
RUN apt-get install -y wget curl gcc gcc-c++ make openssl-devel pcre-devel gd-devel iproute net-tools telnet && \
    yum clean all && \
    rm -rf /var/cache/apt/*
USER root
COPY sunnydale.sh .
ADD nginx-1.15.5.tar.gz /
RUN cd nginx-1.15.5 &&  \
    ./configure --prefix=/usr/local/nginx
    --with-http_ssl_module
    --with-http_stub_status_module && \
    make -j 4 && make install &&  \
    mkdir /usr/local/nginx/conf/vhost && \
    cd / && rm -rf nginx* && \
    ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
USER root
CMD["./sunnydale . sh"]
ENV PATH $PATH:/usr/local/nginx/sbin
COPY nginx.conf /usr/local/nginx/conf/nginx:conf 
WORKDIR /usr/local/nginx
EXPOSE 80
CMD ["nginx","-g","daemon off;"]
EOF

cat << EOF > /home/candidate/KSSC00301/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: couchdb
  namespace: default
  labels:
    app: couchdb
    version: stable
spec:
  replicas: 1
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: couchdb
      version: stable
  template:
    metadata:
      labels:
        run: couchdb
    spec:
      containers:
      - name: couchdb
        image: demo:v1
        imagePullPolicy: IfNotPresent
          livenessProbe:
            httpGet:
              path: /healthCheck
              port: 8080
        ports
        - name: http
          containerPort: 8080
          protocol: TCP
        volumeMounts:
        - name: database-storage
          mountPath: /var/lib/database
        securityContext:
          {"Capabilities": {'add': ['NET_BIND_SERVICE','SYS_ADMIN'], 'drop': ['all']}, 'privileged': False, 'readonlyRootFilesystem': False, 'runAsUser': 65535}
        resources:
          limits:
            cpu: 300m
            memory: 500Mi
          requests:
            cpu: 100m
            memory: 100Mi
EOF

參考資料：

您必須在以下 cluster /節(jié)點上完成此考題:
Cluster Master 節(jié)點 工作節(jié)點
KSSC00301 kssc00301-master kssc00301-worker1

您可以使用以下命令來切換 cluster /配置環(huán)境:
[candidate@cli] $ kubectl config use-context KSSCO0301

Task
分析和編輯給定的 Dockerfile /home/candidate/KSSC00301/Dockerfile (基于 ubuntu:22.04 鏡像)
并修復在文件中擁有突出的安全/最佳實踐問題的兩個指令

分析和編輯給定的清單文件 /home/candidate/KSSCO0301/deployment.yaml并修復在文件中擁有突出的安全/最佳實踐問題的兩個字段

==請勿添加或刪除配置設置; 只需修改現(xiàn)有的配置設置讓以上兩個配置設置都不再有安全/最佳實踐問題卿啡。==

==如果您需要非特權用戶來執(zhí)行任何項目，請使用用戶 ID 65535 的用戶 nobody .==

答題步驟：

注意菱父，本次的 Dockerfile 和 deployment.yaml 僅修改即可颈娜，無需部署剑逃。
<1> 修改 Dockerfile

vi /home/candidate/KSSC00301/Dockerfile
1、僅將 CMD 上面的 USER root 修改為 USER nobody官辽，不要改其他的 USER root蛹磺。
USER nobody
2、修改基礎鏡像為題目要求的 ubuntu:22.04
FROM ubuntu:22.04
#修改后
FROM ubuntu:22.04
RUN apt-get install -y wget curl gcc gcc-c++ make openssl-devel pcre-devel gd-devel iproute net-tools telnet && \
    yum clean all && \
    rm -rf /var/cache/apt/*
USER root
COPY sunnydale.sh .
ADD nginx-1.15.5.tar.gz /
RUN cd nginx-1.15.5 &&  \
    ./configure --prefix=/usr/local/nginx
    --with-http_ssl_module
    --with-http_stub_status_module && \
    make -j 4 && make install &&  \
    mkdir /usr/local/nginx/conf/vhost && \
    cd / && rm -rf nginx* && \
    ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
USER nobody
CMD["./sunnydale . sh"]
ENV PATH $PATH:/usr/local/nginx/sbin
COPY nginx.conf /usr/local/nginx/conf/nginx:conf 
WORKDIR /usr/local/nginx
EXPOSE 80
CMD ["nginx","-g","daemon off;"]



<2> 修改 deployment.yaml
vi /home/candidate/KSSCO0301/deployment.yaml
1同仆、template 里標簽跟上面的內容不一致萤捆，所以需要將原先的 run: couchdb 修改為 app: couchdb
 app: couchdb
#（注意，這里具體要改成 app: couchdb 還是其他的標簽俗批，要以考試給你的 yaml 文件的上下文其他標簽為準俗或，要與另外兩個標簽一致，具體見下方截圖岁忘。）
感謝網友 Tse 和 adams 的反饋和糾正辛慰。

2、刪除 'SYS_ADMIN' 字段干像，確保 'privileged': 為 False 帅腌。（CKS 考試是有多套類似考試環(huán)境的，所以有時是刪 SYS_ADMIN麻汰，有時是改'privileged': False）
#注意 注意速客，如果考試時，本來就沒有'SYS_ADMIN' 字段五鲫，且'privileged':也默認就為 False溺职，則直接將下面綠色的這兩行注釋掉，就是前面加#臣镣。
 securityContext:
 {'Capabilities': {'add': ['NET_BIND_SERVICE'], 'drop': ['all']}, 'privileged': False, 'readonlyRootFilesystem': False, 'runAsUser': 65535}
#修改后

apiVersion: apps/v1
kind: Deployment
metadata:
  name: couchdb
  namespace: default
  labels:
    app: couchdb
    version: stable
spec:
  replicas: 1
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: couchdb
      version: stable
  template:
    metadata:
      labels:
        app: couchdb
    spec:
      containers:
      - name: couchdb
        image: demo:v1
        imagePullPolicy: IfNotPresent
          livenessProbe:
            httpGet:
              path: /healthCheck
              port: 8080
        ports
        - name: http
          containerPort: 8080
          protocol: TCP
        volumeMounts:
        - name: database-storage
          mountPath: /var/lib/database
        securityContext:
          {"Capabilities": {'add': ['NET_BIND_SERVICE'], 'drop': ['all']}, 'privileged': False, 'readonlyRootFilesystem': False, 'runAsUser': 65535}
        resources:
          limits:
            cpu: 300m
            memory: 500Mi
          requests:
            cpu: 100m
            memory: 100Mi
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末辅愿，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子忆某，更是在濱河造成了極大的恐慌点待，老刑警劉巖，帶你破解...
    沈念sama閱讀 212,454評論 6贊 493
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件弃舒，死亡現(xiàn)場離奇詭異癞埠，居然都是意外死亡，警方通過查閱死者的電腦和手機聋呢，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,553評論 3贊 385
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門苗踪，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人削锰，你說我怎么就攤上這事通铲。” “怎么了器贩？”我有些...
    開封第一講書人閱讀 157,921評論 0贊 348
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵颅夺，是天一觀的道長朋截。 經常有香客問我，道長吧黄，這世上最難降的妖魔是什么部服？ 我笑而不...
    開封第一講書人閱讀 56,648評論 1贊 284
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮拗慨，結果婚禮上廓八，老公的妹妹穿的比我還像新娘。我一直安慰自己赵抢，他們只是感情好剧蹂，可當我...
    茶點故事閱讀 65,770評論 6贊 386
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著昌讲，像睡著了一般国夜。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上短绸，一...
    開封第一講書人閱讀 49,950評論 1贊 291
  • 城市分裂傳說
    那天车吹，我揣著相機與錄音，去河邊找鬼醋闭。 笑死窄驹，一個胖子當著我的面吹牛，可吹牛的內容都是我干的证逻。 我是一名探鬼主播乐埠，決...
    沈念sama閱讀 39,090評論 3贊 410
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼囚企！你這毒婦竟也來了丈咐？” 一聲冷哼從身側響起，我...
    開封第一講書人閱讀 37,817評論 0贊 268
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤龙宏，失蹤者是張志新（化名）和其女友劉穎棵逊，沒想到半個月后，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體银酗，經...
    沈念sama閱讀 44,275評論 1贊 303
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡辆影，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,592評論 2贊 327
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了黍特。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片蛙讥。...
    茶點故事閱讀 38,724評論 1贊 341
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖灭衷，靈堂內的尸體忽然破棺而出次慢，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
    沈念sama閱讀 34,409評論 4贊 333
  • ?日本核電站爆炸內幕
    正文 年R本政府宣布经备，位于F島的核電站拭抬，受9級特大地震影響，放射性物質發(fā)生泄漏侵蒙。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點故事閱讀 40,052評論 3贊 316
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一傅蹂、第九天 我趴在偏房一處隱蔽的房頂上張望纷闺。 院中可真熱鬧，春花似錦份蝴、人聲如沸犁功。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,815評論 0贊 21
  • 一樁弒父案婚夫，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽浸卦。三九已至，卻和暖如春案糙，著一層夾襖步出監(jiān)牢的瞬間限嫌，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,043評論 1贊 266
  • 情欲美人皮
    我被黑心中介騙來泰國打工时捌， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留怒医，地道東北人。 一個月前我還...
    沈念sama閱讀 46,503評論 2贊 361
  • 代替公主和親
    正文 我出身青樓奢讨，卻偏偏與公主長得像稚叹，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子拿诸，可洞房花燭夜當晚...
    茶點故事閱讀 43,627評論 2贊 350

推薦閱讀更多精彩內容