7 Review the information entered for this update job. Use the “Previous” button to navigate to other
All changes in this version
Title
Review the information entered for this update job. Use the “Previous” button to navigate to other
Control
tabs in this wizard to change any data, if needed. When ready, click “Start” to start or schedule the update job. 8. To know the status of a scheduled task, choose the “Jobs” option under the “Provisioning” menu. This lists all running or scheduled jobs and provides the capability to cancel them if needed.
B.5.5.3 Remote OS Installation
If an OS is compromised, AMI TruE provides options to remotely re-install a version of the OS that is trusted by your enterprise or datacenter. Follow the steps in Appendix B.5.5.2 , but choose “OS Deployment” in the “Job Type” field. Appendix C—Platform Implementation: Kubernetes
This section contains supplementary information describing all the required components and steps required to set up the prototype implementation for Kubernetes.
C.1 Prototype Architecture
Refer to Figure 7 from Appendix B.1 for the relevant architecture diagram.
C.2 Hardware Description
Refer to the hardware descriptions from Appendix B.2 that are used for the Kubernetes setup.
C.3 Kubernetes Installation and Configuration
Kubernetes deployments minimally consist of controller node(s) and worker node(s), which utilize a specific container runtime. There is a common set of prerequisites that both types of nodes need, and there are unique configurations for each type of node as well. This implementation installs Docker 19.3.5 as the container runtime, and is running kubelet version 1.17.0 as its prerequisite.
Prerequisite installation:
The following commands enable the network traffic overlays for communications between Kubernetes pods within the cluster. # cat > /etc/modules-load.d/containerd.conf <<EOF overlay br_netfilter EOF
# modprobe overlay # modprobe br_netfilter # cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 net.bridge.bridge-nf-call-ip6tables = 1 EOF
# sysctl --system # systemctl enable containerd
The following commands add the Kubernetes repository needed for the software package installations. # cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7- x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF
The following commands install and start the necessary Kubernetes software packages. # dnf install -y kubeadm-1.17.0 kubelet-1.17.0 kubectl-1.17.0 # systemctl enable kubelet # echo 'KUBELET_EXTRA_ARGS="--fail-swap-on=false"' > /etc/sysconfig/kubelet # systemctl start kubelet
Running the following command will produce the output shown in Figure 17 :
# kubectl describe nodes
Figure 17: Kubelet and Docker Versions
C.3.1 Kubernetes Controller Node Configuration
The following command is executed to complete the configuration of the Kubernetes controller node in this implementation by establishing the control-plane overlay network.
# kubeadm init --pod-network-cidr=10.10.20.0/24
Run the following commands to enable the current user, root in this case, to use the cluster. # mkdir -p $HOME/.kube # sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config # sudo chown $(id -u):$(id -g) $HOME/.kube/config
Run the following command to enable Calico as the Container Network Interface (CNI).
# kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
C.3.2 Kubernetes Worker Configuration
Once the controller node is up and running, worker nodes can be joined to the Kubernetes deployment. A token is required to join the worker nodes to the Kubernetes cluster. Run the following on the controller node to obtain the token.
# kubeadm token create --print-join-command
The following command is executed to join worker nodes to the Kubernetes deployment, which is obtained from the previous command.
# kubeadm join 172.16.100.61:6443 --token <token redacted> --discovery- token-ca-cert-hash \ sha256:<hash redacted>
After the worker node is joined to the Kubernetes cluster, run the following command on the controller node to verify the nodes in the cluster are ready:
# kubectl get nodes
C.3.3 Kubernetes Orchestration
In order for the Kubernetes cluster to use the trust measurements and asset tags of hosts in its scheduling policies, the Kubernetes controller node must be configured to communicate with the attestation hub service in the AMI installation. There is an installation binary on the AMI host verification server at /root/binaries/k8s/isecl-k8s-extensions-v2.0.0.bin that needs to be copied to and run on the Kubernetes controller node. This will create Custom Resource Definitions (CRDs) that allow the ISecL trust measurements and asset tags to be leveraged by the Kubernetes scheduler.
A tenant must be created for the Kubernetes hosts, which they must be added to, in the AMI TruE web client. When the tenant is created, the user can choose to associate hosts that are already in the host verification service. After the hosts have been added into the tenant, their trust measurements and asset tags can be used for Kubernetes scheduling policies. In order to enable the trust measurements being used by the Kubernetes scheduler, a few modifications need to be made to the Kubernetes scheduler configurations, and access keys need to be shared between the Kubernetes controller node and the AMI TruE host verification server. The AMI TruE host verification server is built from the ISecL code base; the full steps can be found in Section 6.13.3.2 in the ISecL product documentation at https://01.org/sites/default/files/documentation/intelr_secl-dc_v1.6_ga_product_guide_1.pdf . Appendix D—Supporting NIST SP 800-53 Security Controls
The major controls in the NIST SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations [6] control catalog that affect the container platform security prototype implementation are:
• AU-2, Event Logging
• CA-2, Control Assessments
• CA-7, Continuous Monitoring
• CM-2, Baseline Configuration
• CM-3, Configuration Change Control
• CM-8, System Component Inventory
• IR-4, Incident Handling
• SA-9, External System Services
• SC-1, Policy and Procedures [for System and Communications Protection Family]
• SC-7, Boundary Protection
• SC-29, Heterogeneity
• SC-32, System Partitioning
• SC-36, Distributed Processing and Storage
• SI-2, Flaw Remediation
• SI-3, Malicious Code Protection
• SI-4, System Monitoring
• SI-6, Security and Privacy Function Verification
• SI-7, Software, Firmware, and Information Integrity
Table 7 lists the security capabilities provided by the trusted asset tag prototype:
Table 7: Security Capabilities Provided by the Trusted Asset Tag Prototype
Capability Category Capability Number Capability Name
IC1 – Measurements IC1.1 Measured Boot of BIOS IC1.2 Baseline for BIOS measurement (allowed list) IC1.3 Remote Attestation of Boot Measurements IC1.4 Security Capability & Config Discovery IC2 – Tag Verification IC2.1 Asset Tag Verification
IC3 – Policy Enforcement IC3.1 Policy-Based Workload Provisioning IC3.2 Policy-Based Workload Migration
IC4 – Reporting IC4.1 Support for Continuous Monitoring IC4.2 Support for On-Demand Reports Capability Category Capability Number Capability Name
IC4.3 Support for Notification of Trust Events
IC5 – Remediation IC5.1 Remotely Powering Down a Compromised Platform IC5.2 Updating a Compromised BIOS Firmware IC5.3 Reinstalling a Compromised OS
Table 8 maps the security capabilities from Table 7 to the NIST SP 800-53 controls in the list at the beginning of this appendix.
Table 8: Mapping of Security Capabilities to NIST SP 800-53 Controls
NIST SP 800-53 Control Measurements Tag Verifi- cation Policy Enforcement Reporting Remediation
IC1.1 IC1.2 IC1.3 IC1.4 IC2.1 IC3.1 IC3.2 IC4.1 IC4.2 IC4.3 IC5.1 IC5.2 IC5.3 AU-2 X X X CA-2 X X X CA-7 X X CM-2 X X X CM-3 X X X CM-8 X X IR-4 X X X X SA-9 X X SC-1 X X SC-7 X X X X SC-29 X X SC-32 X X X SC-36 X X X SI-2 X X X SI-3 X X X X X SI-4 X X X X X SI-6 X X X X SI-7 X X X X X X X X Appendix E—Cybersecurity Framework Subcategory Mappings
This appendix maps the major security features of the container platform security prototype implementation to the following Subcategories from the Cybersecurity Framework [7] :
• DE.CM-4: Malicious code is detected
• DE.CM-6: External service provider activity is monitored to detect potential cybersecurity events
• ID.GV-1: Organizational cybersecurity policy is established and communicated
• ID.GV-3: Legal and regulatory requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed
• ID.RA-1: Asset vulnerabilities are identified and documented
• PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity
• PR.IP-3: Configuration change control processes are in place
• PR.IP-5: Policy and regulations regarding the physical operating environment for organizational assets are met
• PR.IP-12: A vulnerability management plan is developed and implemented
• PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy
• RS.MI-1: Incidents are contained
• RS.MI-2: Incidents are mitigated
Table 9 indicates the mappings from the security capabilities in Table 7 in the previous appendix to the Cybersecurity Framework Subcategories listed above.
Table 9: Mapping of Security Capabilities to NIST Cybersecurity Framework Subcategories
Cybersecurity Framework Subcategory Measurements Tag Verifi- cation Policy Enforcement Reporting Remediation
IC1.1 IC1.2 IC1.3 IC1.4 IC2.1 IC3.1 IC3.2 IC4.1 IC4.2 IC4.3 IC5.1 IC5.2 IC5.3 DE.CM-4 X X DE.CM-6 X X X X X X X ID.GV-1 X X ID.GV-3 X X X ID.RA-1 X X X PR.DS-6 X X X X X X X X PR.IP-3 X X X X PR.IP-5 X X X PR.IP-12 X X X PR.PT-1 X X X X X RS.MI-1 X X X RS.MI-2 X X Appendix F—Acronyms and Other Abbreviations
Selected acronyms and abbreviations used in the report are defined below.
AAS Authentication and Authorization Service AIK Attestation Identity Key AMI TruE AMI Trusted Environment API Application Programming Interface BIOS Basic Input/Output System BMC Baseboard Management Controller CA Certificate Authority CMS Certificate Management Service CNI Container Network Interface CoT Chain of Trust CPU Central Processing Unit CRD Custom Resource Definition CRTM Core Root of Trust for Measurement FOIA Freedom of Information Act GB Gigabyte GHz Gigahertz HTML5 Hypertext Markup Language (version 5) HVS Host Verification Service IaaS Infrastructure as a Service Intel TXT Intel Trusted Execution Technology I/O Input/Output IP Internet Protocol IR Interagency or Internal Report IT Information Technology ITL Information Technology Laboratory JSON JavaScript Object Notation KMS Key Management Service KVM Keyboard, Video, Mouse MLE Measured Launch Environment NC Nonce NIST National Institute of Standards and Technology NISTIR National Institute of Standards and Technology Interagency or Internal Report NUC Next Unit of Computing OEM Original Equipment Manufacturer OS Operating System PCR Platform Configuration Register REST Representational State Transfer RHEL Red Hat Enterprise Linux RTM Root of Trust for Measurement RTR Root of Trust for Reporting RTS Root of Trust for Storage SHA256 Secure Hash Algorithm 256-bit SML Stored Measurement Log SMTP Simple Mail Transfer Protocol SP Special Publication SRK Storage Root Key SSDP Simple Service Discovery Protocol SSH Secure Shell TA Trust Agent TPM Trusted Platform Module UEFI Unified Extensible Firmware Interface URL Uniform Resource Locator UUID Universally Unique Identifier WLS Workload Service