forked from docs/doc-exports
qiujiandong1
ab1e53a279
Reviewed-by: Gergo-Bence Lorincz <a200452876@noreply.gitea.eco.tsi-dev.otc-service.com> Co-authored-by: qiujiandong1 <qiujiandong1@huawei.com> Co-committed-by: qiujiandong1 <qiujiandong1@huawei.com>
51 lines
12 KiB
HTML
51 lines
12 KiB
HTML
<a name="cce_bestpractice_0318"></a><a name="cce_bestpractice_0318"></a>
|
|
|
|
<h1 class="topictitle1">Configuration Suggestions on CCE Node Security</h1>
|
|
<div id="body8662426"><div class="section" id="cce_bestpractice_0318__en-us_topic_0000001226756285_section125731371643"><h4 class="sectiontitle">Preventing Nodes from Being Exposed to Public Networks</h4><ul id="cce_bestpractice_0318__en-us_topic_0000001226756285_ul5635110999"><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li263516104912">Do not bind an EIP to a node unless necessary to reduce the attack surface.</li><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li5635151014915">If an EIP must be used, properly configure the firewall or security group rules to restrict access of unnecessary ports and IP addresses.</li></ul>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p10325152114429">You may have configured the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b18197848171612">kubeconfig.json</strong> file on a node in your cluster. kubectl can use the certificate and private key in this file to control the entire cluster. You are advised to delete unnecessary files from the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b8108142218165">/root/.kube</strong> directory on the node to prevent malicious use.</p>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p12555543184410">rm -rf /root/.kube</p>
|
|
</div>
|
|
<div class="section" id="cce_bestpractice_0318__en-us_topic_0000001226756285_section144410272047"><h4 class="sectiontitle">Hardening VPC Security Group Rules</h4><p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p114652430149">CCE is a universal container platform. Its default security group rules apply to common scenarios. Based on security requirements, you can harden the security group rules set for CCE clusters on the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b91050271851712">Security Groups</strong> page of <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b13847012151712">Network Console</strong>.</p>
|
|
</div>
|
|
<div class="section" id="cce_bestpractice_0318__en-us_topic_0000001226756285_section896012361718"><h4 class="sectiontitle">Hardening Nodes on Demand</h4><p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p164510477111">CCE cluster nodes use the default settings of open-source OSs. After a node is created, you need to perform security hardening according to your service requirements.</p>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p54515474120">In CCE, you can perform hardening as follows:</p>
|
|
<ul id="cce_bestpractice_0318__en-us_topic_0000001226756285_ul19571142909"><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li109576421702">Use the post-installation script after the node is created. For details, see the description about <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b1059324225113">Post-installation Script</strong> in <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b188320484515">Advanced Settings</strong> when creating a node. This script is user-defined.</li></ul>
|
|
</div>
|
|
<div class="section" id="cce_bestpractice_0318__en-us_topic_0000001226756285_section71961744466"><h4 class="sectiontitle">Forbidding Containers to Obtain Host Machine Metadata</h4><p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p796335218252">If a single CCE cluster is shared by multiple users to deploy containers, containers cannot access the management address (169.254.169.254) of OpenStack, preventing containers from obtaining metadata of host machines.</p>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p12964195242515">For details about how to restore the metadata, see the "Notes" section in <a href="https://docs.otc.t-systems.com/en-us/usermanual/ecs/en-us_topic_0042400609.html" target="_blank" rel="noopener noreferrer">Obtaining Metadata</a>.</p>
|
|
<div class="warning" id="cce_bestpractice_0318__en-us_topic_0000001226756285_note896420520252"><span class="warningtitle"><img src="public_sys-resources/warning_3.0-en-us.png"> </span><div class="warningbody"><p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p13964195213257">This solution may affect the password change on the ECS console. Therefore, you must verify the solution before rectifying the fault.</p>
|
|
</div></div>
|
|
<ol id="cce_bestpractice_0318__en-us_topic_0000001226756285_ol4410181419216"><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li1041011148211"><span>Obtain the network model and container CIDR of the cluster.</span><p><p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p188112716215">On the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b209605371582">Clusters</strong> page of the CCE console, view the network model and container CIDR of the cluster.</p>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p1655182952116"></p>
|
|
</p></li><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li54171921142111"><span>Prevent the container from obtaining host metadata.</span><p><ul id="cce_bestpractice_0318__en-us_topic_0000001226756285_ul8334817122417"><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li153344176247">VPC network<ol type="a" id="cce_bestpractice_0318__en-us_topic_0000001226756285_ol1709147182414"><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li1709134714249">Log in to each node in the cluster as user <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b1421113391590">root</strong> and run the following command:<pre class="screen" id="cce_bestpractice_0318__en-us_topic_0000001226756285_screen9109045192317">iptables -I OUTPUT -s {container_cidr} -d 169.254.169.254 -j REJECT</pre>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p66011853192413"><em id="cce_bestpractice_0318__en-us_topic_0000001226756285_i16814423101420">{container_cidr}</em> indicates the container CIDR block of the cluster, for example, <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b0814182331412">10.0.0.0/16</strong>.</p>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p884725717242">To ensure configuration persistence, write the command to the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b1685417405716">/etc/rc.local</strong> script.</p>
|
|
</li><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li1370914471249">Run the following commands in the container to access the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b10687111245713">userdata</strong> and <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b446151617575">metadata</strong> interfaces of OpenStack and check whether the request is intercepted:<pre class="screen" id="cce_bestpractice_0318__en-us_topic_0000001226756285_screen159624507230">curl 169.254.169.254/openstack/latest/meta_data.json
|
|
curl 169.254.169.254/openstack/latest/user_data</pre>
|
|
</li></ol>
|
|
</li><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li146002216241">Container tunnel network<ol type="a" id="cce_bestpractice_0318__en-us_topic_0000001226756285_ol1773441712518"><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li107344176256">Log in to each node in the cluster as user <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b34872417577">root</strong> and run the following command:<pre class="screen" id="cce_bestpractice_0318__en-us_topic_0000001226756285_screen1119181152410">iptables -I FORWARD -s {container_cidr} -d 169.254.169.254 -j REJECT</pre>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p117923213256"><em id="cce_bestpractice_0318__en-us_topic_0000001226756285_i11402123791415">{container_cidr}</em> indicates the container CIDR block of the cluster, for example, <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b1840343761412">10.0.0.0/16</strong>.</p>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p1865472210250">To ensure configuration persistence, write the command to the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b660983617578">/etc/rc.local</strong> script.</p>
|
|
</li><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li973418171252">Run the following commands in the container to access the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b1440934025718">userdata</strong> and <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b34103401577">metadata</strong> interfaces of OpenStack and check whether the request is intercepted:<pre class="screen" id="cce_bestpractice_0318__en-us_topic_0000001226756285_screen3787166102414">curl 169.254.169.254/openstack/latest/meta_data.json
|
|
curl 169.254.169.254/openstack/latest/user_data</pre>
|
|
</li></ol>
|
|
</li><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li222510111340">CCE Turbo cluster<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p121461314163415"><a name="cce_bestpractice_0318__en-us_topic_0000001226756285_li222510111340"></a><a name="en-us_topic_0000001226756285_li222510111340"></a>No additional configuration is required for a cluster of a version earlier than v1.23.13-r0, v1.25.8-r0, v1.27.5-r0, or v1.28.3-r0.</p>
|
|
<div class="p" id="cce_bestpractice_0318__en-us_topic_0000001226756285_p14180194713152">For a cluster of v1.23.13-r0, v1.25.8-r0, v1.27.5-r0, v1.28.3-r0, or later version, log in to the CCE console, click the cluster name to access the cluster console. In the navigation pane, choose <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b153719566713">Settings</strong>, click the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b185371856176">Network</strong> tab, and view the value of <span class="uicontrol" id="cce_bestpractice_0318__en-us_topic_0000001226756285_uicontrol553718561771"><b>Pod Access to Metadata</b></span>.<ul id="cce_bestpractice_0318__en-us_topic_0000001226756285_ul9721740128"><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li142401352511">If <span class="uicontrol" id="cce_bestpractice_0318__en-us_topic_0000001226756285_uicontrol6185125211210"><b>Pod Access to Metadata</b></span> is not enabled, no additional configuration is required. The container has been disabled from obtaining the node metadata.</li><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li16689718201219">If <span class="uicontrol" id="cce_bestpractice_0318__en-us_topic_0000001226756285_uicontrol415362951311"><b>Pod Access to Metadata</b></span> is enabled, take the following steps to disable the container from obtaining the node metadata:<ol type="a" id="cce_bestpractice_0318__en-us_topic_0000001226756285_ol11828145411135"><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li682815441312">Log in to each node in the cluster as user <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b1582515160562">root</strong> and run the following command:<pre class="screen" id="cce_bestpractice_0318__en-us_topic_0000001226756285_screen88281754181310">iptables -I FORWARD -s {container_cidr} -d 169.254.169.254 -j REJECT</pre>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p382815411320"><em id="cce_bestpractice_0318__en-us_topic_0000001226756285_i718630195616">{container_cidr}</em> indicates the container CIDR block of the cluster, for example, <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b11863010563">10.0.0.0/16</strong>.</p>
|
|
<p id="cce_bestpractice_0318__en-us_topic_0000001226756285_p1882816542133">To ensure configuration persistence, write the command to the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b145714431564">/etc/rc.local</strong> script.</p>
|
|
</li><li id="cce_bestpractice_0318__en-us_topic_0000001226756285_li582811543136">Run the following commands in the container to access the <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b122661564577">userdata</strong> and <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b226676145713">metadata</strong> interfaces of OpenStack and check whether the request is intercepted:<pre class="screen" id="cce_bestpractice_0318__en-us_topic_0000001226756285_screen88281354121310">curl 169.254.169.254/openstack/latest/meta_data.json
|
|
curl 169.254.169.254/openstack/latest/user_data</pre>
|
|
</li></ol>
|
|
</li></ul>
|
|
</div>
|
|
</li></ul>
|
|
</p></li></ol>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="cce_bestpractice_0315.html">Security</a></div>
|
|
</div>
|
|
</div>
|
|
|