做网站的中文名字,王烨演员,格朗图手表网站,学校建设网站的意义考前须知#xff1a;
1、一共16题#xff0c;100分66分及格#xff0c;考试有两次机会
考试准备#xff1a;
1、护照或或者包含英文名字证件
2、要选择工作日的早上或者晚上考试#xff0c;千万不要选择周末去考#xff0c;否则卡到怀疑人生#xff0c;影响考试结果…考前须知
1、一共16题100分66分及格考试有两次机会
考试准备
1、护照或或者包含英文名字证件
2、要选择工作日的早上或者晚上考试千万不要选择周末去考否则卡到怀疑人生影响考试结果
3、提前1小时等待考试关闭VMwebex、teams等服务就花了30分钟。
题目
第一题 Secret
1 、在namespace istio-system中获取名为db1-test的现有secret的内容将username字段存储在名为 /cks/sec/user.txt的文件中并将password字段存储在名为 /cks/sec/pass.txt的文件中。 注意你必须创建以上两个文件他们还不存在。 注意不要在以下步骤中使用/修改先前创建的文件如果需要可以创建新的临时文件。
k get secrets db1-test -n istio-system -o jsonpath{.data.username} | base64 -d /cks/sec/user.txt
k get secrets db1-test -n istio-system -o jsonpath{.data.password} | base64 -d /cks/sec/pass.txt
2 在istio-system namespace中创建一个名为db2-test的新secret内容如下
username : production-instance
password : KvLftKgs4aVH
k create secrets generic db2-test -n istio-system --from-literalusernameproduction-instance
--from-literalpasswordKvLftKgs4aVH3 最后创建一个新的Pod它可以通过卷访问secret db2-test
Pod 名称 secret-pod
Namespace istio-system
容器名 dev-container
镜像 nginx
卷名 secret-volume
挂载路径 /etc/secret apiVersion: v1
kind: Pod
metadata:name: secret-podnamespace: istio-system
spec:containers:- image: nginxname: dev-containervolumeMounts:- name: secret-volumemountpath: /etc/secretvolumes:- name: secret-volumesecret:secretName: db2-test
第二题Pod指定特定ServiveAccount
1. 在现有namespace qa中创建一个名为backend-sa的新ServiceAccount
确保此ServiceAccount不自动挂载API凭据。
1、#获取sa模板
k create sa backend-sa -n qa --dry-runclient -o yaml sa.yaml
2、编辑sa.yaml 增加不自动挂载api凭据参数
vim sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:name: backend-sanamespace: qa
automountServiceAccountToken: false
3、创建sa
k create -f sa.yaml2. 使用 /cks/sa/pod1.yaml中的清单文件来创建一个Pod。
apiVersion: v1
kind: Pod
metadata:name: backendnamespace: qa
spec:serviceAccountName: backend-sa //就加这一行在链接里有containers:- image: nginx:1.9imagePullPolicy: IfNotPresentname: backend 3. 最后清理namespace ns中任何未使用的ServiceAccount。
k get ns -n qa
k delete sa 名字
第三题Pod安全
检查在 namespace production中运行的Pod并删除任何非无状态或非不可变的 Pod。
使用以下对无状态和不可变的严格解释
l 能够在容器内存储数据的 Pod 的容器必须被视为非无状态的。
注意你不必担心数据是否实际上已经存储在容器中。
l 被配置为任何形式的特权 Pod 必须被视为可能是非无状态和非不可变的。
1、删除privilege的pod
k get pod -n production k get pod 名字 -n production -o yaml | egrep -i priv.*: truek delete pod 名字 -n production第四题默认网络策略
为所有类型为IngressEgress的流量在namespace testing中创建一个名为denypolicy的新默认拒绝NetworkPolicy。
此新的NetworkPolicy必须拒绝namespace testing中的所有的Ingress Egress流量。
将新创建的默认拒绝NetworkPolicy应用与在namespace testing中运行的所有Pod。
你可以在 /cks/net/p1.yaml找到一个模板清单文件。
edit p1.yamlapiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: denypolicynamespace: testing
spec:podSelector: {}policyTypes:- Ingress- Egresskubectl create -f p1.yaml
第五题RBAC
一个名为web-pod的现有Pod已在 namespace db中运行。
编辑绑定到 Pod 的 ServiceAccount service-account-web的现有Role仅允许只对 services类型的资源执行 get操作。
kubectl describe rolebindings -n db
kubectl edit role role-1 -n dbrules:- apiGroups: []resources: [services]verbs: [get]
在namespace db中创建一个名为role-2 并仅允许只对 namespaces类型的资源执行delete操作的新 Role。 k create role role-2 --verbdelete --resourcenamespaces -n db
创建一个名为role-2-binding的新 RoleBinding 将新创建的 Role 绑定到 Pod 的ServiceAccount
k create rolebinding role-2-binding --rolerole-2 --serviceaccountdb: service-account-web -n db
第六题NetworkPolicy
只允许以下Pod连接到Pod products-service
1 namespace qa中的Pod
2 位于任何namespace带有标签environment: testing的Pod
注意确保应用NetworkPolicy。
你可以在/cks/net/po.yaml找到一个模板清单文件
vim po.yaml
apiVersion: networking.k8s.io/v1
kind: NetwokPolicy
metadata:name: pod-restrictionnamespace: dev-team
spec:podSelector: matchLabels:name: testpolicyTypes:- Ingressingress:- from:- namespaceSelector:matchlabels:name: qa- from:- namespaceSelector: {}- podSelector:matchLabels:environment: testing
第七题 Audit日志审计
在cluster中启用审计日志。为此请启用日志后端并确保
l 日志存储在 /var/log/kubernetes/audit-logs.txt
l 日志文件能保留 10 天
l 最多保留 2 个旧审计日志文件 /etc/kubernetes/logpolicy/sample-policy.yaml 提供了基本策略。它仅指定不记录的内容
ssh master
vim /etc/kubernetes/mainfast/kube-apiserver.conf
--audit-policy-path/etc/kubernetes/logpolicy/sample-policy.yaml
--audit-log-path/var/log/kubernetes/audit-logs.txt
--audit-log-maxage10
--audit-log-maxbackup2- mountPath: /etc/kubernetes/logpolicy/sample-policy.yamlname: auditreadOnly: true
- mountPath: /var/log/kubernetes/name: audit-logreadOnly: false
- hostPath:path: /etc/kubernetes/logpolicy/sample-policy.yamltype: Filename: audit
- hostPath:path: /var/log/kubernetes/type: DirectoryOrCreatename: audit-log sytemctl restart kubelet
注意基本策略位于cluster的master节点上。
编辑和扩展基本策略以记录
l RequestResponse 级别的 cronjobs更改
l namespace front-apps中 deployment更改的请求体
l Metadata 级别的所有 namespace 中的 ConfigMap 和 Secret 的更改
此外添加一个全方位的规则以在 Metadata 级别记录所有其他请求。 #注意 这里是resources的[]里资源对象要加s
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:- RequestReceived
rules:- level: RequestResponse resources:- group: resources: [cronjobs]- level: Request resources:- group: resources: [deployments]namespaces: [front-apps]- level: Metadata resources:- group: resources: [configmaps,secrets]- level: Metadata omitStages:- RequestReceivedk apply -f yaml
第七题 Dockerfile检测
#dockerfile
修改两处 #user root 改为 user nobody
修改 image: ubuntu:latest 为 ubuntu:19.2
#deployment.yaml
第一种答案
注释security context这行
第二种答案
把securityContext:这里的privileged改为false然后用户改为runAsUser: 65535
第八题 Gvisor
该 cluster使用 containerd作为CRI运行时。containerd的默认运行时处理程序是runc。
containerd已准备好支持额外的运行时处理程序runsc (gVisor)。
使用名为runsc的现有运行时处理程序创建一个名为untrusted 的RuntimeClass。
更新 namespace server中的所有Pod以在gVisor上运行。
#编写yaml
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:name: untrusted
handler: runsc
#创建
k create -f yaml
#查询
kubectl get RuntimeClassk eidt deployment web1 -n client
在 spec下面添加 runtimeClassName: untrusted
第九题Trivy扫描镜像安全漏洞
使用Trivy开源容器扫描器检测namespace kamino中 Pod 使用的具有严重漏洞的镜像。
查找具有High或Critical严重性漏洞的镜像并删除使用这些镜像的Pod。
ssh master
k get pod -n kamino --outputcustom-columnsName:.metadata.name,IMAGE: .spec.containers[*].image
trivy image -s HIGH,CRITICAL amonzline:1k delete pod xxxxx -n kamino --force
第十题 Sisdig
使用运行时检测工具来检测 Pod tomcat 单个容器中频发生成和执行的异常进程
有两种工具可供使用
l sysdig
l falco
注 这些工具只预装在cluster的工作节点不在 master 节点。
使用工具至少分析30秒 使用过滤器检查生成和执行的进程将事件写到 /opt/KSR00101/incidents/summary文件中
其中包含检测的事件 格式如下
[timestamp],[uid],[processName]
保持工具的原始时间戳格式不变。
注 确保事件文件存储在集群的工作节点上
docker ps | grep tomcat
找到containerid
sysdig -M 30 -P %evt.time,%user.uid,%proc.name container.idID号 指定的log名字
第十一题 启用 API server认证
重新配置cluster的Kubernetes APl 服务器以确保只允许经过身份验证和授权的 REST请求。
使用授权模式 Node,RBAC 和准入控制器 NodeRestriction。
#备份
ssh master
cp /etc/kubernets/mainfast/kube-apiserver.yaml ~/
vim /etc/kubernets/mainfast/kube-apiserver.yaml
- --authorization-modeNode,RBAC
- --enable-admission-pluginsNodeRestrictionsystemctl resatrt kubelet
删除用户 system:anonymous 的 ClusterRoleBinding来进行清理。 注意所有kubectl 配置环境/文件也被配置使用未经身份验证和未经授权的访问。
你不必更改它但请注意一旦完成 cluster 的安全加固 kubectl 的配置将无法工作。
您可以使用位于 cluster 的 master 节点上cluster 原本的 kubectl 配置文件
/etc/kubernetes/admin.conf 以确保经过身份验证的授权的请求仍然被允许。
k delete clusterrolebinding system:anonymous
第十二题 kube-bench修复
kube-bench 是一个 CIS 评估工具扫描 kubernetes 集群存在的安全问题 基本上按照 扫描结果的修复建议进行修复就可以了系统会给出很具体的修复措施。
# 修复 kube-apiserver 安全问题
#修改--authorization-modeNode,RBAC
#添加--insecure-port0
#删除# --insecure-bind-address0.0.0.0#修复 kubelet 安全问题
vi /var/lib/kubelet/config.yaml
# 将authentication.anonymous.enabled 设置为 false
authentication:anonymous:enabled: false
# authorization.mode 设置为 Webhook
authorization:mode: Webhook# 修复 etcd 安全问题
vi /etc/kubernetes/manifests/etcd.yaml
# 修改为true
- --client-cert-authtrue
# 以上修复完成后 重新加载配置文件并重启kubelet
systemctl daemon-reload
systemctl restart kubelet
第十三题 ImagePolicyWebhook容器镜像扫描
给定一个目录 /etc/kubernetes/epconfig中不完整的配置以及具有 HTTPS 端点
https://acme.local:8082/image_policy 的功能性容器镜像扫描器
1. 启用必要的插件来创建镜像策略
最后通过尝试部署易受攻击的资源 /cks/img/web1.yaml来测试配置是否有效。
你可以在 /var/log/imagepolicy/roadrunner.log 找到容器镜像扫描仪的日志文件。
ssh master
vim /etc/kubernetes/mainfast/kube-apiserver.yaml
- -- enable-admission-pluginsNodeRestriction,ImagePolicyWebhook
- --admission-contorl-config-file/etc/kubernetes/epconfig/admission_configrtion.yaml
- mountPath: /etc/kubernetes/epconfigname: k8s-admissreadOnly: true
- hostPath:path: /etc/kubernetes/epconfigtype: DirectoryOrCreatename: k8s-admisssystemctl restart kubelet2. 校验控制配置并将其更改为隐式拒绝implicit deny
cd /etc/kubernetes/epconfig
vim admission_configrtion.yaml
修改 allowdefalut false
3. 编辑配置以正确指向提供的 HTTPS 端点
cd /etc/kubernetes/epconfig
vim kubeconfig.yaml
在cluster下面增加
server: https://acme.local:8082/image_policy
第十四题 PSP
创建一个名为restrict-policy的新的PodSecurityPolicy以防止特权Pod的创建。
最后创建一个名为dany-access-bind的ClusterRoleBinding
你可以在一下位置找到模版清单文件
/cks/psp/psp.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:name: restrict-policy #改下名字
spec:privileged: false # 修改为false seLinux: rule: RunAsAnysupplementalGroups:rule: RunAsAnyrunAsUser:rule: RunAsAnyfsGroup:rule: RunAsAnyvolumes:- *k create -f psp.yaml 在现有的namespace staging中创建一个名为psp-denial-sa的新ServiceAccount。
kubectl create sa psp-denial-sa -n staging创建一个名为restrict-access-role并使用新创建的PodSecurityPolicy restrict-policy的ClusterRole。
kubectl create clusterrole restrict-access-role --verbuse --resourcepsp --resource-namerestrict-policy
将新创建的ClusterRole restrict-access-role绑定到新创建的ServiceAccount psp-denial-sa。 kubectl create clusterrolebinding dany-access-bind --clusterrolerestrict-access-role --serviceaccountstaging:psp-denial-sa
第十五题AppArmor
在 cluster 的工作节点上实施位于 /etc/apparmor.d/nginx_apparmor的现有APPArmor 配置文件。 编辑位于 /home/candidate/KSSH00401/nginx-deploy.yaml的现有清单文件以应用 AppArmor 配置文件。 最后应用清单文件并创建其中指定的 Pod 。
ssh master
apparmor_parser -q /etc/apparmor.d/nginx_apparmorapiVersion: v1
kind: Pod
metadata:name: podx annotations: #添加这一部分container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3
spec:containers:- image: busyboximagePullPolicy: IfNotPresentname: podx #这个就是containers下的名字为podxcommand: [ sh, -c, echo Hello AppArmor! sleep 1h ]resources: {}nodeName: node01dnsPolicy: ClusterFirstrestartPolicy: Always
status: {}kubectl apply -f /home/candidate/KSSH00401/nginx-deploy.yaml
