forked from docs/doc-exports
Reviewed-by: Eotvos, Oliver <oliver.eotvos@t-systems.com> Co-authored-by: Dong, Qiu Jian <qiujiandong1@huawei.com> Co-committed-by: Dong, Qiu Jian <qiujiandong1@huawei.com>
43 lines
9.1 KiB
HTML
43 lines
9.1 KiB
HTML
<a name="cce_bestpractice_0318"></a><a name="cce_bestpractice_0318"></a>
|
|
|
|
<h1 class="topictitle1">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_i81301222175615">{container_cidr}</em> indicates the container CIDR of the cluster, for example, <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b17482229145617">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_i18649133375716">{container_cidr}</em> indicates the container CIDR of the cluster, for example, <strong id="cce_bestpractice_0318__en-us_topic_0000001226756285_b116506332578">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.</p>
|
|
</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>
|
|
|