forked from docs/doc-exports
qiujiandong1
bfc6e41869
Reviewed-by: Eotvos, Oliver <oliver.eotvos@t-systems.com> Co-authored-by: qiujiandong1 <qiujiandong1@huawei.com> Co-committed-by: qiujiandong1 <qiujiandong1@huawei.com>
46 lines
8.3 KiB
HTML
46 lines
8.3 KiB
HTML
<a name="cce_bestpractice_10046"></a><a name="cce_bestpractice_10046"></a>
|
|
|
|
<h1 class="topictitle1">Configuration Suggestions on CCE Container Runtime Security</h1>
|
|
<div id="body8662426"><p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p86371427142211">Container technology uses Linux namespaces and cgroups to isolate and control resources between containers and nodes. Namespaces provide kernel-level isolation, allowing processes to be restricted from accessing specific sets of resources, such as file systems, networks, processes, and users. Cgroups are a Linux kernel feature that manages and limits the usage of resources, such as CPU, memory, disk, and network, to prevent a single process from consuming too many resources and negatively impacting the overall system performance.</p>
|
|
<p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p86254211222">While namespaces and cgroups isolate resources between containers and nodes in an environment, node resources are not visible to containers. However, this isolation does not provide true security isolation because containers share the kernels of their nodes. If a container exhibits malicious behavior or a kernel vulnerability is exploited by attackers, the container may breach resource isolation. This can result in the container escaping and potentially compromising the node and other containers on the node.</p>
|
|
<p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p1062114211229">To enhance runtime security, there are various mechanisms that can be used to detect and prevent malicious activities in containers. These mechanisms, such as capabilities, seccomp, AppArmor, and SELinux, can be integrated into Kubernetes. By using these mechanisms, container security can be improved and potential threats can be minimized.</p>
|
|
<div class="section" id="cce_bestpractice_10046__en-us_topic_0000002011467409_section14284116132316"><h4 class="sectiontitle">Capabilities</h4><p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p2240558172317">Capabilities are a permission mechanism that enables a process to perform certain system operations without requiring full root permissions. This mechanism divides root permissions into smaller, independent permissions known as capabilities. By doing so, the process only obtains the minimum permission set necessary to complete its tasks. This approach enhances system security and helps mitigate potential security risks.</p>
|
|
<p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p4241105819237">In a containerized environment, you can manage a container's capabilities by configuring its <strong id="cce_bestpractice_10046__en-us_topic_0000002011467409_b515816338455">securityContext</strong>. The following is a configuration example:</p>
|
|
<pre class="screen" id="cce_bestpractice_10046__en-us_topic_0000002011467409_screen17371232240">...
|
|
securityContext:
|
|
capabilities:
|
|
add:
|
|
- NET_BIND_SERVICE
|
|
drop:
|
|
- all</pre>
|
|
<p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p461125742410">In this way, you can ensure that the container only has the necessary permissions to complete its tasks. This approach eliminates the risk of security breaches caused by excessive permissions. For more information about how to configure capabilities for a container, see <a href="https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container" target="_blank" rel="noopener noreferrer">Set capabilities for a Container</a>.</p>
|
|
</div>
|
|
<div class="section" id="cce_bestpractice_10046__en-us_topic_0000002011467409_section1953145942918"><h4 class="sectiontitle">Seccomp</h4><p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p593994413012">Seccomp is a mechanism that filters system calls, limiting the ones that processes can use to decrease the potential attack surface. Linux has many system calls, but not all are needed for containerized applications. By restricting the system calls that containers can execute, you can greatly reduce the risk of attacks on your applications.</p>
|
|
<p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p8417124810316">Seccomp's main principle is to intercept all system calls and only allow trusted ones to pass. Container runtimes, such as Docker and containerd, come with default seccomp configurations that work for most common workloads.</p>
|
|
<div class="p" id="cce_bestpractice_10046__en-us_topic_0000002011467409_p6940194419305">In Kubernetes clusters, you can configure seccomp policies for containers to use the default security configuration. The following shows how to configure seccomp in different versions of Kubernetes clusters:<ul id="cce_bestpractice_10046__en-us_topic_0000002011467409_ul1974610163328"><li id="cce_bestpractice_10046__en-us_topic_0000002011467409_li1746191611326">For clusters of versions earlier than Kubernetes 1.19, you can use the following annotations to specify the seccomp configuration:<pre class="screen" id="cce_bestpractice_10046__en-us_topic_0000002011467409_screen199481339103217">annotations:
|
|
seccomp.security.alpha.kubernetes.io/pod: "runtime/default"</pre>
|
|
</li><li id="cce_bestpractice_10046__en-us_topic_0000002011467409_li5746111619325">For clusters of Kubernetes 1.19 and later versions, you can use <strong id="cce_bestpractice_10046__en-us_topic_0000002011467409_b1424305715151">securityContext</strong> to configure seccomp policies.<pre class="screen" id="cce_bestpractice_10046__en-us_topic_0000002011467409_screen4475651173215">securityContext:
|
|
seccompProfile:
|
|
type: RuntimeDefault</pre>
|
|
</li></ul>
|
|
</div>
|
|
<p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p12772158113315">These configurations use the default seccomp policy, which permits containers to make a limited number of secure system calls. For more configuration options and advanced settings of seccomp, see <a href="https://kubernetes.io/docs/tutorials/security/seccomp/" target="_blank" rel="noopener noreferrer">Restrict a Container's Syscalls with seccomp</a>.</p>
|
|
</div>
|
|
<div class="section" id="cce_bestpractice_10046__en-us_topic_0000002011467409_section02697449349"><h4 class="sectiontitle">AppArmor and SELinux</h4><p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p12678103619355">AppArmor and SELinux are both Mandatory Access Control (MAC) systems that offer a more stringent approach than traditional Discretionary Access Control (DAC) to manage and restrict process permissions. While similar to seccomp in concept, these systems provide more precise access control, including access to file system paths, network ports, and other resources.</p>
|
|
<p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p76781436123519">AppArmor and SELinux enable administrators to create policies that precisely manage the resources that applications can access. They can limit read and write permissions on specific files or directories, or regulate access to network ports.</p>
|
|
<div class="p" id="cce_bestpractice_10046__en-us_topic_0000002011467409_p1167810367358">Both systems are integrated into Kubernetes, allowing security policies to be applied at the container level.<ul id="cce_bestpractice_10046__en-us_topic_0000002011467409_ul28221452113610"><li id="cce_bestpractice_10046__en-us_topic_0000002011467409_li14822175211362">For details about how to use AppArmor, see <a href="https://kubernetes.io/docs/tutorials/security/apparmor/" target="_blank" rel="noopener noreferrer">Restrict a Container's Access to Resources with AppArmor</a>.</li><li id="cce_bestpractice_10046__en-us_topic_0000002011467409_li11822952153613">For SELinux, you can configure <strong id="cce_bestpractice_10046__en-us_topic_0000002011467409_b1977399122520">seLinuxOptions</strong> in <strong id="cce_bestpractice_10046__en-us_topic_0000002011467409_b1928331362512">securityContext</strong>.<pre class="screen" id="cce_bestpractice_10046__en-us_topic_0000002011467409_screen11768171513719">...
|
|
securityContext:
|
|
seLinuxOptions:
|
|
level: "s0:c123,c456"</pre>
|
|
<p id="cce_bestpractice_10046__en-us_topic_0000002011467409_p2082214524368">For details, see <a href="https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container" target="_blank" rel="noopener noreferrer">Assign SELinux labels to a Container</a>.</p>
|
|
</li></ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="cce_bestpractice_0315.html">Security</a></div>
|
|
</div>
|
|
</div>
|
|
|