Node Security
Preventing Nodes from Being Exposed to Public Networks
- Do not bind an EIP to a node unless necessary to reduce the attack surface.
- If an EIP must be used, properly configure the firewall or security group rules to restrict access of unnecessary ports and IP addresses.
You may have configured the kubeconfig.json 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 /root/.kube directory on the node to prevent malicious use.
rm -rf /root/.kube
Hardening VPC Security Group Rules
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 Security Groups page of Network Console.
Hardening Nodes on Demand
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.
In CCE, you can perform hardening as follows:
- Use the post-installation script after the node is created. For details, see the description about Post-installation Script in Advanced Settings when creating a node. This script is user-defined.
Forbidding Containers to Obtain Host Machine Metadata
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.
For details about how to restore the metadata, see the "Notes" section in Obtaining Metadata.
This solution may affect the password change on the ECS console. Therefore, you must verify the solution before rectifying the fault.
- Obtain the network model and container CIDR of the cluster.
On the Clusters page of the CCE console, view the network model and container CIDR of the cluster.
- Prevent the container from obtaining host metadata.
- VPC network
- Log in to each node in the CCE cluster as user root and run the following command:
iptables -I OUTPUT -s {container_cidr} -d 169.254.169.254 -j REJECT
{container_cidr} indicates the container CIDR of the cluster, for example, 10.0.0.0/16.
To ensure configuration persistence, you are advised to write the command to the /etc/rc.local script.
- Run the following commands in the container to access the userdata and metadata interfaces of OpenStack and check whether the request is intercepted:
curl 169.254.169.254/openstack/latest/meta_data.json curl 169.254.169.254/openstack/latest/user_data
- Log in to each node in the CCE cluster as user root and run the following command:
- Container tunnel network
- Log in to each node in the CCE cluster as user root and run the following command:
iptables -I FORWARD -s {container_cidr} -d 169.254.169.254 -j REJECT
{container_cidr} indicates the container CIDR of the cluster, for example, 10.0.0.0/16.
To ensure configuration persistence, you are advised to write the command to the /etc/rc.local script.
- Run the following commands in the container to access the userdata and metadata interfaces of OpenStack and check whether the request is intercepted:
curl 169.254.169.254/openstack/latest/meta_data.json curl 169.254.169.254/openstack/latest/user_data
- Log in to each node in the CCE cluster as user root and run the following command:
- No additional configuration is required for CCE Turbo clusters.
- VPC network
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot