Securing a containerized application relies on multiple levels of security. You may have heard about Security Context Constraints (SCCs), which are unique to OpenShift, and wondered what they are for. SCCs are objects that can be used to control the actions that a pod can perform and what resources it can access.
Because SCCs are OpenShift objects, you can use the normal create, get, describe, etc. verbs with the SCCs, although you do need to be logged in with admin privileges in order to change or delete SCCs. OpenShift includes eight predefined Security Context Constraints that your pod can use. You can see the list by running the command:
oc get scc
SCC NAME
anyuid
hostaccess
hostmount-anyuid
hostnetwork
node-exporter
nonroot
privileged
restricted
By default, a pod is secured by the 'restricted' SCC, but there may be cases where you want to customize an SCC according to your own requirements. Red Hat does not recommend modifying the default SCCs, so you need to create your own. Then when your pod is started, OpenShift checks for a match between the requested privileges for pods and containers within the deployment and the available set of SCCs. If there is a match, the pod is accepted otherwise it's rejected. Ready to learn how? Watch this video where Barry Mosakowski demonstrates how to build a custom SCC, add it to your pod, and then validate that it is working.
For a more in depth explanation of SCCs and how to use them with pod service accounts or role based access control, check out this OpenShift blog.
#Featured-area-1#Featured-area-1-home#Openshift#Containers#security