Security Considerations#
Before installing the Intel® Geti™ platform, the server environment must be prepared. Work with your IT department to gather the network-related configuration parameters and ensure all enterprise security requirements are met.
Customer should run the Platform in an environment with strict network boundaries, such as on-premises datacenter with physical network firewalls or Virtual Networks in Public Cloud.
It is advisable to configure additional available server-specific modules (firewall, QoS) to protect the Platform against resource exhaustion attacks and denial of service (DoS) problems.
The following ports are used by the platform:
22/tcp: SSH access (in case the machine is accessed remotely), protected with password-based authentication,
80/tcp: redirect to 443/tcp, Strict-Transport-Security is enforced,
443/tcp: Platform UI interface,
6443/tcp: Kubernetes API server port on master nodes, protected certificate-based authentication,
30000/tcp: platform internal registry port, protected with Transport Layer Security (TLS) and Basic authentication.
It is advisable to restrict access to 22/tcp and 6443/tcp ports so that SSH and Kubernetes API server accept connections from trusted machines only. Please, consult your firewall vendor’s documentation for configuration instructions.
On all nodes constituting the cluster, the port 30000/tcp should be configured as unavailable from outside of the machine - as it exposes the internal platform container registry. If this port won’t be secured - machines outside of the cluster will have access to container images used by the cluster. Please, consult your firewall vendor’s documentation for configuration instructions.
The Platform user interface uses port 443/tcp with HTTPS. The customer can provide a custom TLS certificate during installation, otherwise installation of the Platform uses a self-signed TLS certificate generated during installation. It is advisable to use custom TLS certificate specific to your organization generated by your organization or a trusted certificate authority (CA).
Ensure that the platform’s port 443/tcp can be accessed from the host where the platform is installed when using the external IP or DNS name used during the installation or changed afterwards when running platform_change_ip.sh.
All the data uploaded to the Platform and produced using the Platform is accessible by system (Ubuntu) administrators and system users that have access to the data storage folder configured during the installation.
It is advisable to use strong passwords for system users.
Customer should scan data uploaded to the Platform using antivirus.
It is advisable to use NIST “Guide to General Server Security” recommendations and follow the steps below to reduce the Platform host OS attack surface:
harden hosts and keep them up to date,
do not run other apps, like a web server or database, on hosts that run containers,
do not run unnecessary system services on hosts that run containers,
maintain a schedule to continuously scan hosts and the appropriate lower-level components for vulnerabilities and updates, such as with the kernel,
enable Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) on servers.
If necessary, e.g., when a storage device is released or decommissioned, customer shall delete unprotected sensitive data securely in accordance with industry and government-accepted standards for secure deletion.
The Intel® Geti™ platform system administrator is responsible for Intel® Geti™ keys, certificates and secret rotation using the provided automation script Intel® Geti™ at least once per 90 days. The Intel® Geti™ platform system administrator is responsible for Intel® Geti™ keys, certificates and secret destruction upon its expiration or compromise.
The Intel® Geti™ platform uses email as login - these emails may appear in application logs. The system administrator should apply additional controls to protect logs in order to avoid leakage of logins.
The Intel® Geti™ platform retains the collected telemetry data (logs, metrics, traces) for a period of 30 days after collection. Customers may use a logs export feature to store logs in a separate storage system if it is required.
The Intel® Geti™ platform uses 1001 and 10001 user IDs to run containers. Ensure that user IDs used by the Platform are not conflicted with the host’s user table and do not have unnecessary root privileges.
Administrative activities#
TLS certificate/key replacement#
To replace Platform UI TLS certificate, please follow the steps listed below:
Delete existing key/certificate secrets by running:
kubectl delete secret custom-tls -n ingress-nginx
Navigate to the directory where new TLS key/certificate files are stored.
Create a new secret by running:
kubectl create secret tls custom-tls --key <key file name> --cert <cert file name> -n ingress-nginx
Restart nginx deployment by running:
kubectl rollout restart deployment ingress-nginx-controller -n ingress-nginx
Certificates & passwords’ rotation#
To regenerate secrets/passwords in various components in the Platform, please use the utility rotate_secrets located in Platform package platform_<VERSION>/rotation_script providing the components’ names, e.g.:
cd platform_<VERSION>/rotation_script
./rotate_secrets cookies jwt kafka mongodb
Before rotating JWT token secret, please make sure that there are no active invitations or password reset requests, otherwise the links sent to the users will become invalid.
Rotation of Redis secret will logout all users that are signed in the application.
Component |
Rotation identifier |
---|---|
Cookies |
cookies |
JWT |
jwt |
Kafka passwords |
kafka |
SpiceDB preshared key |
spicedb |
Zookeeper passwords |
zookeeper |
Dex secret |
dex |
Internal Registry |
registry |
MongoDB passwords |
mongodb |
PostgresSQL |
postgresql |
Redis |
redis |
SeaweedFS |
seaweedfs |