## 참고로, scc는 namespace마다 있는 것이 아니다.
## 따라서 namespace를 지정하지 않고, 아래 명령처럼 scc를 생성한다.
$ oc apply -f my-scc.yaml
이렇게 생성한 SCC를 내가 사용할 ServiceAccount와 binding한다.
$ oc create ns andrew-project
$ oc adm policy add-scc-to-group andrew-scc system:serviceaccounts:andrew
$ oc adm policy add-scc-to-user andrew-scc -z andrew -n andrew-project
# SCC 정보를 확인하는 명령
$ oc describe scc andrew-scc
# 'andrew' ServiceAccount로부터 'andrew-scc' SCC를 삭제하는 명령
$ oc adm policy remove-scc-from-user andrew-scc -z andrew -n andrew-project
추가로 Pod Deploy할 때, 아래와 같이 'securityContext' 항목을 설정해야 한다.
# File name: my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: ubuntu-pv
labels:
app: ubuntu-pv
spec:
replicas: 1
selector:
matchLabels:
app: ubuntu-pv
template:
metadata:
labels:
app: ubuntu-pv
spec:
## NOTE: 이 부분을 추가 !!!
securityContext:
runAsUser: 0
containers:
- name: ubuntu-pv
image: myharbor.andrew.space:8080/my-ubuntu:0.1.2
## NOTE: 이 부분을 추가 !!!
securityContext:
capabilities:
add:
- "NET_ADMIN"
- "NET_RAW"
- "NET_BIND_SERVICE"
여기까지는 그냥 SecurityContextConstraints에 관한 이해없이 따라해도 잘 동작한다.
그런데 만약 SecurityContextConstraints에 대해서 깊이 있는 지식을 얻고 싶다면, 아래의 Red Hat Blog를 읽어볼 것을 추천한다.
SecurityContextConstraints 방식으로 Process의 실행 권한을 제어하는 방법 외에도 Linux에서 전통적으로 사용하는 Stick Bit(SETUID)와 File Capability 방식으로 Binary File을 만들고, Container Image를 미리 제작하는 방법도 같이 소개하고 있다.
어떤 방식이 더 편하고, 보안(Security)이 우수한지는 사용하는 사람이 판단할 일이다.