From 73e7f8ef4cc9b6390912de798ee6b42d0de40b88 Mon Sep 17 00:00:00 2001 From: Oliver Date: Mon, 6 Jun 2022 13:24:01 -0400 Subject: [PATCH] Security Planning shall support customer expectations Epic: Security Planning shall support expectations presented in pre-sales presentations. Updated with review comments for Patch set 4 Updated with review comments for Patch set 3 Updated with review comments from Patch set 2 Updated with review comments from Patch set 1 Added summaries of items raised in pre-sales presentations Change-Id: Ic1e458dfd57ad7ab18923f3a1756007ad717efe1 --- doc/source/.vscode/settings.json | 3 +- .../container-security-df8a251ec03f.rst | 128 ++++++++++++ .../index-planning-kub-913bd621ac0f.rst | 46 ++++- .../kubernetes/infrastructure-security.rst | 189 ++++++++++++++++++ ...ingx-internal-cloud-management-network.rst | 0 .../local-and-ldap-linux-user-accounts.rst | 0 .../local-linux-account-for-sysadmin.rst | 0 .../secure-https-external-connectivity.rst | 0 .../security-hardening-firewall-options.rst | 0 .../kubernetes/security-hardening-intro.rst | 0 ...ity-planning-uefi-secure-boot-planning.rst | 54 ----- .../ssh-and-console-login-timeout.rst | 0 .../kubernetes/starlingx-accounts.rst | 0 .../system-account-password-rules.rst | 0 .../kubernetes/uefi-secure-boot.rst | 0 .../web-administration-login-timeout.rst | 0 .../openstack/uefi-secure-boot-planning.rst | 3 +- .../index-security-kub-81153c1254c3.rst | 40 ---- 18 files changed, 363 insertions(+), 100 deletions(-) create mode 100644 doc/source/planning/kubernetes/container-security-df8a251ec03f.rst create mode 100755 doc/source/planning/kubernetes/infrastructure-security.rst rename doc/source/{security => planning}/kubernetes/isolate-starlingx-internal-cloud-management-network.rst (100%) rename doc/source/{security => planning}/kubernetes/local-and-ldap-linux-user-accounts.rst (100%) rename doc/source/{security => planning}/kubernetes/local-linux-account-for-sysadmin.rst (100%) rename doc/source/{security => planning}/kubernetes/secure-https-external-connectivity.rst (100%) rename doc/source/{security => planning}/kubernetes/security-hardening-firewall-options.rst (100%) rename doc/source/{security => planning}/kubernetes/security-hardening-intro.rst (100%) delete mode 100755 doc/source/planning/kubernetes/security-planning-uefi-secure-boot-planning.rst rename doc/source/{security => planning}/kubernetes/ssh-and-console-login-timeout.rst (100%) rename doc/source/{security => planning}/kubernetes/starlingx-accounts.rst (100%) rename doc/source/{security => planning}/kubernetes/system-account-password-rules.rst (100%) rename doc/source/{security => planning}/kubernetes/uefi-secure-boot.rst (100%) rename doc/source/{security => planning}/kubernetes/web-administration-login-timeout.rst (100%) diff --git a/doc/source/.vscode/settings.json b/doc/source/.vscode/settings.json index 3cce948f6..ba18b6198 100644 --- a/doc/source/.vscode/settings.json +++ b/doc/source/.vscode/settings.json @@ -1,3 +1,4 @@ { - "restructuredtext.confPath": "" + "restructuredtext.confPath": "", + "esbonio.sphinx.confDir": "" } \ No newline at end of file diff --git a/doc/source/planning/kubernetes/container-security-df8a251ec03f.rst b/doc/source/planning/kubernetes/container-security-df8a251ec03f.rst new file mode 100644 index 000000000..bcf0f9d46 --- /dev/null +++ b/doc/source/planning/kubernetes/container-security-df8a251ec03f.rst @@ -0,0 +1,128 @@ +.. _container-security-df8a251ec03f: + +=========================== +Container Security Planning +=========================== + +The following container security best practices are recommended as part of your +network security planning. + +Restrict Direct (SSH) Access to Kubernetes Nodes +------------------------------------------------ + +To reduce the risk of unauthorized access to host resources, only system +administrators should be allowed SSH access to |prod| nodes. Non-system admin +users should be restricted to helm and kubectl for remote access. + +Use Role-based Access Control (RBAC) +------------------------------------ + +Define RBAC policies to exercise strict control over permissions granted to +non-admin users. Restrict non-admin users to the minimum level of privileges. + +Use Namespaces +-------------- + +Use Namespaces to partition application resources into logical groups to allow +the creation of RBAC policies to managing access to these resources as a whole. + +Use Network Policies +-------------------- + +Use network policies to restrict pod-to-pod traffic to approved profiles. + +Segregate Sensitive Workloads +----------------------------- + +Use a combination of node taints and pod toleration to ensure that pods do not +get scheduled onto inappropriate nodes. + +For sole-tenant nodes, use node selectors to segregate applications from +tenants on different worker nodes to minimize container-escape scope to +applications of the sole-tenant. + +Define Resource Quotas and Resource Limits Policies +--------------------------------------------------- + +Do not allow the configuration of resource-unbounded containers as this puts +the system at risk of Denial-of-Service or “noisy neighbor” scenarios. + +Specify Minimal-Required Security Context for Pods +-------------------------------------------------- + +Explicitly specify the minimal-required security context for pods, containers +and volumes through pod security policies, for example: + +- runAsNonRoot + +- Capabilities + +- readOnlyRootFilesystem + +--------------- +Kata Containers +--------------- + +Kata containers are an optional capability on |prod| that provide a secure +container runtime with lightweight virtual machines that feel and perform like +containers, but provide stronger workload isolation. For improved performance +wrt isolation, Kata containers leverages hardware-enforced isotation with +virtualization VT extensions. + +For more information, see :ref:`starlingx-kubernetes-user-tutorials-overview`. + +--------------------- +Pod Security Policies +--------------------- + +Pod security policies provide a cluster-level resource that controls the use +of security-sensitive aspects of Pod security. PodSecurityPolicies (PSP) define +different levels of access to security-sensitive aspects of the pod. RBAC +[Cluster]Roles can then be created for these PSPs, with RBAC +[Cluster]RoleBindings of these roles to a ‘subject’ (i.e. users, groups, +serviceaccounts, etc.). + +The following considerations apply to PodSecurityPolicies (PSPs): + +- includes enabling or disabling options such as running as root, access to + host filesystem, access to host networking, etc. + +- are disabled by default + +- can be enable by the System Administor via **system service-parameter-add + kubernetes kube_apiserver admission_plugins=PodSecurityPolicy** + +|prod| provides default PSP and RBAC definitions to simplify initial +usage: + +- Define a ‘restrictive’ and ‘privileged’ PSP, and corresponding + representative RBAC Roles + +- Define initial RBAC RoleBindings for these roles such that: + + - cluster-admin can still perform anything / anywhere + + - authenticated users can only perform a restricted set of + security-sensitive options on Pods and only in namespaces the user + is allowed to access + +Administrator can then: + +- create other custom PodSecurityPolicies and associated RBAC Roles + +- create [Cluster]RoleBindings to the appropriate ‘subjects’. + + +------------------------------------ +Container Image Signature Validation +------------------------------------ + +The Portieris admission controller allows you to enforce image security polices +to: + +- enforce trust pinning and blocks creation of resources that use untrusted + images + +- access trusted data in Notary server corresponding to the image + +For more information about Portieris, including installation instructions, see :ref:'portieris-overview'. diff --git a/doc/source/planning/kubernetes/index-planning-kub-913bd621ac0f.rst b/doc/source/planning/kubernetes/index-planning-kub-913bd621ac0f.rst index 6e80d398d..f54c02126 100644 --- a/doc/source/planning/kubernetes/index-planning-kub-913bd621ac0f.rst +++ b/doc/source/planning/kubernetes/index-planning-kub-913bd621ac0f.rst @@ -8,9 +8,9 @@ :start-after: kub-begin :end-before: kub-end -************ +------------ Introduction -************ +------------ .. toctree:: :maxdepth: 1 @@ -96,7 +96,47 @@ Security planning .. toctree:: :maxdepth: 1 - security-planning-uefi-secure-boot-planning + infrastructure-security + container-security-df8a251ec03f + +Security hardening Guidelines +***************************** + +.. toctree:: + :maxdepth: 1 + + security-hardening-intro + +Recommended Security Features with a Minimal Performance Impact +--------------------------------------------------------------- + +.. toctree:: + :maxdepth: 1 + + uefi-secure-boot + +Secure System Accounts +---------------------- + +.. toctree:: + :maxdepth: 1 + + local-linux-account-for-sysadmin + local-and-ldap-linux-user-accounts + starlingx-accounts + web-administration-login-timeout + ssh-and-console-login-timeout + system-account-password-rules + +Security Features +----------------- + +.. toctree:: + :maxdepth: 1 + + secure-https-external-connectivity + security-hardening-firewall-options + isolate-starlingx-internal-cloud-management-network ********************************** Installation and resource planning diff --git a/doc/source/planning/kubernetes/infrastructure-security.rst b/doc/source/planning/kubernetes/infrastructure-security.rst new file mode 100755 index 000000000..f5901aa3b --- /dev/null +++ b/doc/source/planning/kubernetes/infrastructure-security.rst @@ -0,0 +1,189 @@ + +.. qzw1552672165570 +.. _infrastructure_security: + +======================= +Infrastructure Security +======================= + +A key aspect of planning your installation and configuration is addressing +infrastructure security. By planning your configuration to include industry +standard best practices prior to deployment, you can reduce the risk of +security and compliance issues. + +--------------------------------------- +|prod| Infrastructure Security Features +--------------------------------------- + +The security features listed below are available with |prod| and should be +included in your infrastructure security planning. + +- Regular CVE scanning and fixing of |prod| Platform’s CentOS Kernel and RPM + Packages + +- UEFI Secure Boot on |prod| Hosts + + - Signed boot loaders, initramfs, kernel and kernel modules + + - Signed in formal builds with |prod| private key on |prod| secure + signing server + + - Validated by board-specific UEFI Secure Boot Firmware + + For more information, see :ref:`Kubernetes_UEFI_Secure_Boot_Planning` + +- Signed ISOs and Patches/Updates + + - Signed in formal builds with |prod| private key on |prod| secure + signing server + + - Public key built into ISO and patch signature validation code + + - Signatures checked on load import and update import commands + +- Authentication and Authorization on all interfaces of: + + - SSH / Local Console (local LDAP) + + - Linux User/Group Permissions + + - Linux sudo + + - |prod| REST APIs/CLIs (Keystone - local DB) + + - Keystone Roles - admin, member + + - Kubernetes APIs/CLIs (Service Accounts and Remote LDAP / Windows + Active Directory via OIDC/DEX) + + - K8S RBAC Policies + + - |prod| Dashboard Webserver (Keystone - Local DB) + + - Keystone Roles - admin, member + + - Local Docker Registry (Keystone - Local DB) + + - Keystone - admin, non-admin user + +- HTTPS Support for all external Platform endpoints including: + + - System, Kubernetes, local docker registry REST APIs + + - Platform Dashboard Webserver + + - Certificate Management for K8S Certificates + + - Bootstrap configured K8S Root CA Certificates (auto-generated or + user-specified) + + - Cron Jobs for renewing K8S server & client Certificates + + - Procedure for updating K8S Root CA Certificate + + - Certificate Management for HTTPS Platform endpoints (StarlingX APIs, + Registry, OIDC, …) including use of Cert-Manager for install and + auto-renewal of Certificates + + + - Trusted CA Management for local client-side certificate validation + + - Alarming of soon-to-expired and expired Certificates + + - ‘show-certs.sh’ for displaying status and residual time for all + certificates. + +- Secure (HTTPS) Platform management network communication in Distributed + Cloud providing secure management network connectivity between the system + controller and subclouds with auto-renewal of certificates + +- OAM / API Firewall includes default firewall rules automatically applied + and customer modifiable through Calico network policies + +- Helm v3 support including the removal of the default use of Helmv2/Tiller + (insecure) + +- Secure User Management including: + + - User Password Complexity enforcement + + - User forced log out on idle activity + + - User temporary lock out on N consecutive authentication failures + +- Audit logs for operator commands and authentication events + + - Shell commands (on SSH / Local Console) + + - StarlingX REST APIs / CLIs + + - All logs can be sent to external Log Server using Wind River Analytics + application + +- Linux Auditd support for running on all hosts with configurable rules + +- OpenScap Modules included in Host ISO + +- Security Services for Hosted Applications including: + + - Cert Manager support including integration of the cert-manager project + to automate the management and issuance of TLS certificates from + various issuing sources (e.g. interface with external CA for + certificate signing, auto-renewal of certificates) + + - Secure secret management and storage (Hashicorp Vault) with the + integration of upstream Hashicorp Vault project and Support Vault + general secret management for hosted applications + +.. _Kubernetes_UEFI_Secure_Boot_Planning: + +------------------------------------ +Kubernetes UEFI Secure Boot Planning +------------------------------------ + +|UEFI| Secure Boot Planning allows you to authenticate modules before they are +allowed to execute. + +The initial installation of |prod| should be done in |UEFI| mode if you plan on +using the secure boot feature in the future. + +The |prod| secure boot certificate can be found in the |prod| ISO, on the EFI +bootable FAT filesystem. The file is in the directory /CERTS. You must add this +certificate database to the motherboard's |UEFI| certificate database. How to +add this certificate to the database is determined by the |UEFI| implementation +provided by the motherboard manufacturer. + +You may need to work with your hardware vendor to have the certificate +installed. + +There is an option in the |UEFI| setup utility that allows a user to browse to +a file containing a certificate to be loaded in the authorized database. This +option may be hidden in the |UEFI| setup utility unless |UEFI| mode is enabled, +and secure boot is enabled. + +Many motherboards ship with Microsoft secure boot certificates pre-programmed +in the |UEFI| certificate database. These certificates may be required to boot +|UEFI| drivers for video cards, |RAID| controllers, or |NICs| \(for example, +the |PXE| boot software for a |NIC| may have been signed by a Microsoft +certificate\). While certificates can be removed from the certificate database +\(this is |UEFI| implementation specific\) it may be required that you keep the +Microsoft certificates to allow for complete system operation. + +Mixed combinations of secure boot and non-secure boot nodes are supported. For +example, a controller node may secure boot, while a worker node may not. Secure +boot must be enabled in the |UEFI| firmware of each node for that node to be +protected by secure boot. + +.. _security-planning-uefi-secure-boot-planning-ul-h4z-lzg-bjb: + +- Secure Boot is supported in |UEFI| installations only. It is not used when + booting |prod| as a legacy boot target. + +- |prod| does not currently support switching from legacy to |UEFI| mode + after a system has been installed. Doing so requires a reinstall of the + system. This means that upgrading from a legacy install to a secure boot + install \(|UEFI|\) is not supported. + +- When upgrading a |prod| system from a version that did not support secure + boot to a version that does, do not enable secure boot in |UEFI| firmware + until the upgrade is complete. diff --git a/doc/source/security/kubernetes/isolate-starlingx-internal-cloud-management-network.rst b/doc/source/planning/kubernetes/isolate-starlingx-internal-cloud-management-network.rst similarity index 100% rename from doc/source/security/kubernetes/isolate-starlingx-internal-cloud-management-network.rst rename to doc/source/planning/kubernetes/isolate-starlingx-internal-cloud-management-network.rst diff --git a/doc/source/security/kubernetes/local-and-ldap-linux-user-accounts.rst b/doc/source/planning/kubernetes/local-and-ldap-linux-user-accounts.rst similarity index 100% rename from doc/source/security/kubernetes/local-and-ldap-linux-user-accounts.rst rename to doc/source/planning/kubernetes/local-and-ldap-linux-user-accounts.rst diff --git a/doc/source/security/kubernetes/local-linux-account-for-sysadmin.rst b/doc/source/planning/kubernetes/local-linux-account-for-sysadmin.rst similarity index 100% rename from doc/source/security/kubernetes/local-linux-account-for-sysadmin.rst rename to doc/source/planning/kubernetes/local-linux-account-for-sysadmin.rst diff --git a/doc/source/security/kubernetes/secure-https-external-connectivity.rst b/doc/source/planning/kubernetes/secure-https-external-connectivity.rst similarity index 100% rename from doc/source/security/kubernetes/secure-https-external-connectivity.rst rename to doc/source/planning/kubernetes/secure-https-external-connectivity.rst diff --git a/doc/source/security/kubernetes/security-hardening-firewall-options.rst b/doc/source/planning/kubernetes/security-hardening-firewall-options.rst similarity index 100% rename from doc/source/security/kubernetes/security-hardening-firewall-options.rst rename to doc/source/planning/kubernetes/security-hardening-firewall-options.rst diff --git a/doc/source/security/kubernetes/security-hardening-intro.rst b/doc/source/planning/kubernetes/security-hardening-intro.rst similarity index 100% rename from doc/source/security/kubernetes/security-hardening-intro.rst rename to doc/source/planning/kubernetes/security-hardening-intro.rst diff --git a/doc/source/planning/kubernetes/security-planning-uefi-secure-boot-planning.rst b/doc/source/planning/kubernetes/security-planning-uefi-secure-boot-planning.rst deleted file mode 100755 index 575f5ebab..000000000 --- a/doc/source/planning/kubernetes/security-planning-uefi-secure-boot-planning.rst +++ /dev/null @@ -1,54 +0,0 @@ - -.. qzw1552672165570 -.. _security-planning-uefi-secure-boot-planning: - -==================================== -Kubernetes UEFI Secure Boot Planning -==================================== - -|UEFI| Secure Boot Planning allows you to authenticate modules before they are -allowed to execute. - -The initial installation of |prod| should be done in |UEFI| mode if you plan on -using the secure boot feature in the future. - -The |prod| secure boot certificate can be found in the |prod| ISO, on the EFI -bootable FAT filesystem. The file is in the directory /CERTS. You must add this -certificate database to the motherboard's |UEFI| certificate database. How to -add this certificate to the database is determined by the |UEFI| implementation -provided by the motherboard manufacturer. - -You may need to work with your hardware vendor to have the certificate -installed. - -There is an option in the |UEFI| setup utility that allows a user to browse to -a file containing a certificate to be loaded in the authorized database. This -option may be hidden in the |UEFI| setup utility unless |UEFI| mode is enabled, -and secure boot is enabled. - -Many motherboards ship with Microsoft secure boot certificates pre-programmed -in the |UEFI| certificate database. These certificates may be required to boot -|UEFI| drivers for video cards, |RAID| controllers, or |NICs| \(for example, -the |PXE| boot software for a |NIC| may have been signed by a Microsoft -certificate\). While certificates can be removed from the certificate database -\(this is |UEFI| implementation specific\) it may be required that you keep the -Microsoft certificates to allow for complete system operation. - -Mixed combinations of secure boot and non-secure boot nodes are supported. For -example, a controller node may secure boot, while a worker node may not. Secure -boot must be enabled in the |UEFI| firmware of each node for that node to be -protected by secure boot. - -.. _security-planning-uefi-secure-boot-planning-ul-h4z-lzg-bjb: - -- Secure Boot is supported in |UEFI| installations only. It is not used when - booting |prod| as a legacy boot target. - -- |prod| does not currently support switching from legacy to |UEFI| mode - after a system has been installed. Doing so requires a reinstall of the - system. This means that upgrading from a legacy install to a secure boot - install \(|UEFI|\) is not supported. - -- When upgrading a |prod| system from a version that did not support secure - boot to a version that does, do not enable secure boot in |UEFI| firmware - until the upgrade is complete. diff --git a/doc/source/security/kubernetes/ssh-and-console-login-timeout.rst b/doc/source/planning/kubernetes/ssh-and-console-login-timeout.rst similarity index 100% rename from doc/source/security/kubernetes/ssh-and-console-login-timeout.rst rename to doc/source/planning/kubernetes/ssh-and-console-login-timeout.rst diff --git a/doc/source/security/kubernetes/starlingx-accounts.rst b/doc/source/planning/kubernetes/starlingx-accounts.rst similarity index 100% rename from doc/source/security/kubernetes/starlingx-accounts.rst rename to doc/source/planning/kubernetes/starlingx-accounts.rst diff --git a/doc/source/security/kubernetes/system-account-password-rules.rst b/doc/source/planning/kubernetes/system-account-password-rules.rst similarity index 100% rename from doc/source/security/kubernetes/system-account-password-rules.rst rename to doc/source/planning/kubernetes/system-account-password-rules.rst diff --git a/doc/source/security/kubernetes/uefi-secure-boot.rst b/doc/source/planning/kubernetes/uefi-secure-boot.rst similarity index 100% rename from doc/source/security/kubernetes/uefi-secure-boot.rst rename to doc/source/planning/kubernetes/uefi-secure-boot.rst diff --git a/doc/source/security/kubernetes/web-administration-login-timeout.rst b/doc/source/planning/kubernetes/web-administration-login-timeout.rst similarity index 100% rename from doc/source/security/kubernetes/web-administration-login-timeout.rst rename to doc/source/planning/kubernetes/web-administration-login-timeout.rst diff --git a/doc/source/planning/openstack/uefi-secure-boot-planning.rst b/doc/source/planning/openstack/uefi-secure-boot-planning.rst index c5a9e0f7a..725e38c39 100755 --- a/doc/source/planning/openstack/uefi-secure-boot-planning.rst +++ b/doc/source/planning/openstack/uefi-secure-boot-planning.rst @@ -8,5 +8,4 @@ UEFI Secure Boot Planning You may want to plan for utilizing the supported |UEFI| secure boot feature. -See :ref:`Kubernetes UEFI Secure Boot Planning -` for details. +See :ref:`infrastructure_security` for details. diff --git a/doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst b/doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst index 224422e82..849aff051 100644 --- a/doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst +++ b/doc/source/security/kubernetes/index-security-kub-81153c1254c3.rst @@ -223,46 +223,6 @@ Security Feature Configuration for Spectre and Meltdown security-feature-configuration-for-spectre-and-meltdown -***************************** -Security Hardening Guidelines -***************************** - -.. toctree:: - :maxdepth: 1 - - security-hardening-intro - -Recommended Security Features with a Minimal Performance Impact -*************************************************************** - -.. toctree:: - :maxdepth: 1 - - uefi-secure-boot - -Secure System Accounts -********************** - -.. toctree:: - :maxdepth: 1 - - local-linux-account-for-sysadmin - local-and-ldap-linux-user-accounts - starlingx-accounts - web-administration-login-timeout - ssh-and-console-login-timeout - system-account-password-rules - -Security Features -***************** - -.. toctree:: - :maxdepth: 1 - - secure-https-external-connectivity - security-hardening-firewall-options - isolate-starlingx-internal-cloud-management-network - ************************ Deprecated Functionality ************************