Kubernetes platform security considerations

Edit online
In a cloud environment, you must restrict access to your resources and data to authorized users. Data security can be built up by physical arrangements and software checks. Use zero trust principles and centrally managed deployments on dedicated servers that can be accessed only by authorized users. You must also protect your network with secure routes.

The following sections describe the key considerations to successfully secure your deployments on the cloud.

For more information about how to configure your OpenShift clusters to protect and secure your data, see Configuring cluster security.

FIPS enablement

A container deployment can be configured to be Federal Information Processing Standards (FIPS)-compliant. The FIPS enablement must be configured, as it is disabled by default. For more information, see FIPS compliance.

User management

User management is controlled by authentication and authorization functions.

Authentication
The ability for a user to identify themselves by using a username and password, token, or keys as having an account to access the platform.
Authorization
The distinct roles and authorizations that are attached to a user that define what actions they can complete on the platform. Examples include anonymous, view only, project based, cluster admin, and certain namespaces.

Various roles are often involved in the installation: developers, system and cloud administrators, operations, and DevOps teams. Each of these teams interacts with the infrastructure in a distinct way.

The cloud administration team is responsible for configuring the physical infrastructure for running your cluster. The operations team maintains the cluster through security settings, patching, upgrading, and scaling. DevOps teams configure continuous delivery activities, monitoring, logging, rolling upgrades, and deployments. Developers consume the API and the resources that are exposed by the infrastructure.

A Cluster Administrator is likely to create teams of users that need access to certain resources based on the Identity Management (IM) role. An IM role defines the actions that a user can take on the team resources.

The minimum RBAC role that is needed to install is the Operator role. However, if redeployment and cleanup are needed then the user needs to have the Administrator role. For more information, see Role-based access control (RBAC).

Similar to the way that RBAC resources control user access, administrators can use security context constraints (SCC) to control permissions for pods in addition to the Red Hat OpenShift default SCCs. These permissions include actions that a pod can take and what resources it can access. Privileged is the most relaxed SCC policy and must be used only for cluster administration. It gives complete control over the host worker nodes and containers, and the ability to run as any user, any group, any fsGroup, and with any SELinux context. Grant with caution, particularly in production, and monitor the access and actions of the administrators to spot bad behavior.

Security Context Constraints

All instances run in the default restricted security context constraint (SCC) that comes with OpenShift. For more information, see Managing Security Context Constraints in OpenShift.

HTTP vulnerabilities

By default, the deployed services are configured to accept communications over HTTPS. If you change the default deployment to allow communication over HTTP, the applications that use these services like the administration console for Content Platform Engine, can be vulnerable to denial of service (DoS and DDoS) attacks like Slowloris.

You can mitigate against these kinds of attacks by:

  • Putting an efficient HTTP proxy in front of your web or application servers.
  • Using hardware load balancers that accept only full HTTP connections.
    Note: Some restrictions exist when you use load balancers for Content Platform Engine. For more information, see Load balancer support for FileNet P8.
  • Using Mod_reqtimeout to set limits on the time it takes to receive an HTTP request.
    For example:
    <IfModule mod_reqtimeout.c>
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
</IfModule>

You can also mitigate during the implementation by:

  • Refusing connections with abnormally small advertised window size.
  • Refusing persistent connections and HTTP pipe lining (unless performance benefits can be gained by accepting them).
  • Limiting the absolute connection life time to a reasonable value.
  • Tracking the rate at which a client is sending data and disconnecting when a bad client is identified.
  • Configuring the maximum transaction time for the client. If the sending message does not happen within the transaction time set at the server, drop the client connection.
  • Using an edge server that sets its buffer and passes on the data over to the application server only when the buffer is full.

Routes, ingress, and egress

Routes are used to provide external access to cluster resources. External access is provided by routes, egress, or ingress. The container deployment secures the routes of its services by using transport layer security (TLS) termination to serve certificates to the client.

The following ciphers can be used for TLS communications:
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

All dependent services, including database servers and LDAP servers, must configure one of these four ciphers to secure communication with the container components.

To mitigate potential attacks on your deployments, outbound connections are limited by default to a minimum to deny all egress.
  • Network policies are created during the installation for specific pods to connect to the services that they need.
  • Network policies are created for traffic between the components.
  • Network policies are created for traffic to known endpoints like databases.

In a development environment, you might set the sc_restricted_internet custom resource parameter to false because you cannot know where the applications are calling. In a production environment, it is important to set the sc_restricted_internet parameter to true, and to create additional egress network policies to specifically allow communication to trusted external destinations. You can create the egress network policies with a single network policy or individual network policies for each component. For more information about the components that need to access external services, see Configuring cluster security.

Secrets

A root certificate authority (CA) secret stores the root CA TLS key and certificate. Every component also trusts the certificates that are stored in a certificate list, which can be configured in an operator instance. For more information, see Managing certificates.

The following tables provide the minimum set of secrets that need to be created for the operator deployment. In most cases, if self-signed certificates are sufficient, these secrets can be created by the operator. It does not include the secrets that you can set at the component level. Component-level parameters always take precedence over the shared configuration parameters.

Every component route potentially needs two certificates:
  • A TLS certificate that is stored in a TLS secret.
  • An optional CA signer that is stored in a generic Kubernetes secret.
Note: When you create secrets, special characters such as $, \, *, =, and ! are interpreted by your shell, and therefore need escaping. In most shells, the simplest way to escape a password is to surround it with single quotation marks ('). For example, if your password is S!B\*d$zDsb= then run the command with single quotation marks around the password string. 
kubectl create secret generic dev-db-secret \
   --from-literal=username=devuser \
   --from-literal=password='S!B\*d$zDsb='

You do not need to escape special characters in passwords from files (--from-file). For more information, see Managing Secrets.

Table 1. Shared configuration parameters for operator certificates
Parameter Value type Description
shared_configuration
root_ca_secret TLS secret Root CA for all internal services.
external_tls_certificate_secret TLS secret Wildcard certificate for all external routes.
sc_ingress_tls_secret_name TLS secret Ingress certificate for Red Hat OpenShift Kubernetes Service (ROKS).

Also, the deployment contains components that communicate with external services and resources. For communication with those services, the components need to provide certificate information to the operator. The shared configuration parameter trusted_certificate_list contains the list of such certificates. Or, the component-level CR parameter for external services such as the LDAP or databases contains the certificate information.