Overview

The WebLogic Server (WLS) team is investing in new integration capabilities for running WLS in Kubernetes and Docker cloud environments. As part of this effort, we have identified best practices for securing Docker and Kubernetes environments when running WebLogic Server.

These best practices are in addition to the general WebLogic Server recommendations found in the Oracle® Fusion Middleware Securing a Production Environment for Oracle WebLogic Server 12c documentation.

 

 

Ensuring the Security of WebLogic Server Running in Your Docker Environment

References to Docker Security Resources

These recommendations are based on documentation and white papers from a variety of sources. These include:

 

Summary of Recommendations

The recommendations to secure your production environment are:

  1. Validate your Docker configuration using the CIS Docker benchmark. This can be done manually or automatically using a 3rd party tool.
  2. Validate your Host Operating System configuration using the appropriate CIS Operating System benchmark.
  3. Evaluate additional host hardening recommendations not already covered by the CIS Benchmarks.
  4.  Evaluate additional container runtime recommendations not already covered by the CIS Benchmarks.

These are described in more detail in the following sections.

Validate Your Docker Configuration Using the Center for Internet Security (CIS) Docker Benchmark

The Center for Internet Security (CIS) produces a benchmark for both Docker Community Edition and multiple Docker EE versions. The latest benchmark is for Docker EE 1.13 and new benchmarks are added after new Docker EE versions are released. These benchmarks contain ~100 detailed recommendations for securely configuring Docker. The recommendations apply to both the host and the Docker components and are organized around the following topics:

  • Host configuration
  • Docker daemon configuration
  • Docker daemon configuration files
  • Container Images and Build File
  • Container Runtime
  • Docker Security Operations
  • Docker Swarm Configuration

For more information, refer to detailed benchmark document  – https://www.cisecurity.org/benchmark/docker/

You should validate your configuration against each CIS Docker Benchmark recommendation either manually or via an automated tool. You can find a list of CIS partner benchmark tools that can validate your Docker configuration on http://www.cisecurity.org. These include (in alphabetical order):

Note: the CIS Benchmarks require a license to use commercially. For more information, refer to https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/.

 

Validate Your Host Operating System (OS) Using the CIS Benchmark

The Center for Internet Security (CIS) also produces a benchmark for various Operating Systems including different Linux flavors, AIX, Solaris, Microsoft Windows, OSX, etc.

These benchmarks contain a set of detailed recommendations for securely configuring your Host OS. For example, the CIS Oracle Linux 7 Benchmark contains over 200 recommendations and over 300 pages of instructions. The recommendations apply to all aspects of Linux configuration.

For more information, refer to detailed benchmark document  – https://www.cisecurity.org/cis-benchmarks/

You should validate your configuration against the appropriate CIS Operating System Benchmark either manually or via an automated tool. You can find a list of CIS partner benchmark tools that can validate your Operating System configuration on http://www.cisecurity.org. For example, for CIS Oracle Linux 7, this includes  (in alphabetical order):

 

Additional Host Hardening Recommendations

Beyond the CIS benchmarks, there are additional host hardening recommendations and information that should be considered. These include:

  • Use Grsecurity and PAX
  • NCC Group Host Hardening Recommendations

Grsecurity and PaX

The grsecurity project provides various patches to the Linux kernel that enhance a system’s overall security. This includes address space protection, enhanced auditing and process control.

PaX flags data memory such as the stack as non-executable and program memory as non-writable. PaX also provides address space layout randomization.

Grsecurity and PAX can be run on the kernel used for Docker without requiring changes in Docker configuration. The security features will apply to the entire host and therefore to all containers. You may want to investigate grsecurity and PaX to determine if they can be used in your production environment. For more information, refer to http://grsecurity.net.

NCC Group Host Hardening Recommendations

The NCC group white paper (NCC group Understanding Hardening Linux Containers) contains additional recommendations for hardening Linux containers: 

There is overlap between these recommendations and the CIS Docker Benchmarks. The recommendations in the two sections:

  • 10.1 Generation Container Recommendations
  • 10.3 Docker Specific Recommendations 

include additional host hardening items. This includes:

  • Keep the kernel as up to date as possible.
  • Typical sysctl hardening should be applied. 

  • Isolate storage for containers and ensure appropriate security.
  • Control device access and limit resource usage using Control Groups (cgroups)

You may want to investigate these recommendations further; for more information, refer to NCC group Understanding Hardening Linux Containers

Additional Container Runtime Recommendations

Beyond the CIS Docker recommendations, there are additional container runtime recommendations that should be considered. These include:

  • Use a custom seccomp profile either created manually or with help from a tool such as Docker Slim.
  • Utilize the Docker Security Enhanced Linux (SELinux) profile.
  • Specify additional restricted Linux kernel capabilities when starting Docker.
  • Improve isolation and reduce attack surface by running only Docker on the host server.
  • Additional container hardening based on NCC group recommendations.

Run with a Custom seccomp Profile

Secure computing mode (seccomp) is a Linux kernel feature that can be used to restrict the actions available within the container. This feature is available only if Docker has been built with seccomp and the kernel is configured with CONFIG_SECCOMP enabled. Oracle Linux 7 supports seccomp and Docker runs with a seccomp profile by default.

The default seccomp profile provides a good default for running containers with seccomp and disables around 44 system calls out of 300+.  It is not recommended to change the default seccomp profile, but you can run with a custom profile using the 

    –security-opt seccomp=/path/to/seccomp/profile.json

option. For more information on the seccomp default profile, refer to https://docs.docker.com/engine/security/seccomp/#passing-a-profile-for-a-container

If the default seccomp profile is not sufficient for your Docker production environment, then you can optionally create a custom profile and run with it. A tool such as Docker Slim (https://github.com/docker-slim/docker-slim) may be useful in generating a custom seccomp profile via static and dynamic analysis.

Run with SELinux

Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides a mechanism for supporting access control security policies, including mandatory access controls (MAC). You can enable SELinux when starting the Docker container.

To enable SELinux, ensure that SELinux is installed

    yum install selinux-policy

then enable the docker SELinux module 

    semodule -v -e docker

and then specify that SELinux is enabled when starting Docker

    # vi /etc/sysconfig/docker

    OPTIONS=’–selinux-enabled –group=docker -g /scratch/docker’

Run with Restricted Capabilities

Docker runs containers with a restricted set of Linux kernel capabilities. You can specify additional capabilities to remove based on the requirements of your environment. For more information, refer to https://docs.docker.com/engine/security/security/#linux-kernel-capabilities.

Run Only Docker on Server

In order to ensure isolation of resources and reduce the attack surface, it is recommended to run only Docker on the server. Other services should be moved to Docker containers.

NCC Group Docker Container Hardening Recommendations

The NCC group white paper contains additional recommendations for hardening Linux containers: NCC group Understanding Hardening Linux Containers

There is overlap between these recommendations and those listed in prior sections and in the CIS Benchmarks. The recommendations in the two sections:

  • 10.1 Generation Container Recommendations
  • 10.3 Docker Specific Recommendations 

include additional Docker container hardening items. This includes:

  • Control device access and limit resource usage using Control Groups (cgroups)
  • Isolate containers based on trust and ownership. Have one application per container if feasible.
  • Use layer two and layer three firewall rules to limit container to host and guest to guest communication.
  • Use Docker container auditing tools such as Clair, drydock, and Project Natilus.

For more information on these recommendations, refer to NCC group Understanding Hardening Linux Containers. 

 

 

Ensuring the Security of WebLogic Server Running in Your Kubernetes Production Environment

 

References to Kubernetes Security Resources

These recommendations are based on documentation and whitepapers from a variety of sources. These include:

Summary of Recommendations

The recommendations to secure your environment are:

  1. Validate your Kubernetes configuration using the CIS Kubernetes benchmark. This can be done manually or automatically using a 3rd party tool.
  2. Evaluate additional Kubernetes runtime recommendations not already covered by the CIS Benchmarks.

These are described in more detail in the following sections.

 

Validate Your Kubernetes Configuration Using the CIS Kubernetes Benchmark

The Center for Internet Security (CIS) produces a benchmark for Kubernetes. This benchmarks contain a set of detailed recommendations for securely configuring Kubernetes with ~ 250 pages in the benchmark. The recommendations apply to the various Kubernetes components and are organized around the following topics:

  • Master Node Security Configuration including API Server, Scheduler, Controller Manager, configuration files and etcd.
  • Worker Node Security Configuration including Kubelet and configuration files.
  • Federated Deployments including Federation API Server and Federation Controller Manager.

For more information, refer to https://www.cisecurity.org/benchmark/kubernetes/

You should validate your configuration against each CIS Kubernetes Benchmark recommendation either manually or via an automated tool. You can find a list of CIS partner benchmark tools that can validate your Kubernetes configuration on http://www.cisecurity.org. These include (in alphabetical order):

Note: the CIS Benchmarks require a license to use commercially. For more information, refer to https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/.

 

Additional Container Runtime Recommendations

Beyond the CIS Kubernetes recommendations, there are additional container runtime recommendations that should be considered.

Images

Images should be free of vulnerabilities and should be retrieved from either from a trusted registry or from a private registry. Image scanning should be performed to ensure there are no security vulnerabilities. You should use third party tools to perform the CVE scanning and you should integrate these into the build process.

For more information, refer to http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html.

Security Context and Pod Security Policy

Security policies can be set at the pod or container level via the security context. The security context can be used to:

  • Make the Container run as Non-root user
  • Control capabilities used in container.
  • Make the root file system read-only
  • Prevent container with user running as root from the pod.

For more information, refer to https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ and http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html.

Secure Access to Nodes

You should avoid using SSH access to Kubernetes nodes, reducing the risk for unauthorized access to host resource. Use kubectl exec instead of SSH. If debugging of issues is required, create a separate staging environment that allows for SSH access. 

Separate Resources

A Kubernetes namespace allows you to partition created resources into logically named groups. Resources created in one namespace can be hidden from other namespaces.  You can create additional namespaces and attach resources and users to them.  You can utilize resource quotas attached to a namespace for memory, CPU, and pods.

For more information, refer to http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html.

Manage Secrets

A secret contains sensitive data such as a password, token, or key. Secrets can be mounted as data volumes or be exposed as environment variables to be used by a container in a pod. They can also be used by other parts of the system, without being directly exposed to the pod. You should:

  • Manage user and pod access to secrets.
  • Store secrets securely
  • Don’t use files or environment variables for secrets.

For more information, refer to https://kubernetes.io/docs/concepts/configuration/secret/.

Networking Segmentation

Segment the network so different applications do not run on the same Kubernetes cluster. This reduces the risk of one compromised application attacking a neighboring application. Network segmentation ensures that containers can not communicate with other containers unless authorized. For more information, refer to Network Segmentation in http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html