Cómo crear una imagen de sistema de archivos de solo lectura para TIBCO BWCE

por Alexandre Vazquez
2025-11-03

Este artículo cubrirá cómo mejorar la seguridad de tus imágenes de TIBCO BWCE creando una Imagen de Sistema de Archivos de Solo Lectura para TIBCO BWCE. En artículos anteriores, hemos comentado los beneficios que este tipo de imagen proporciona varias ventajas en términos de seguridad, centrándonos en aspectos como la reducción de la superficie de ataque al limitar el tipo de cosas que cualquier usuario puede hacer, incluso si logran acceder a contenedores en ejecución.

Lo mismo se aplica en caso de que cualquier malware que pueda tener tu imagen haya limitado las posibles acciones que pueden hacer sin ningún acceso de escritura a la mayor parte del contenedor.

¿Cómo afecta ReadOnlyFileSystem a una imagen de TIBCO BWCE?

Esto tiene un impacto claro ya que la imagen de TIBCO BWCE es una imagen que necesita escribir en varias carpetas como parte del comportamiento esperado de la aplicación. Eso es obligatorio y no depende de los scripts que usaste para construir tu imagen.

Como probablemente sepas, TIBCO BWCE incluye dos conjuntos de scripts para construir la imagen base de Docker: los principales y los incluidos en la carpeta reducedStartupTime, como puedes ver en la página de GitHub pero también dentro de tu carpeta docker en el TIBCO-HOME después de la instalación, como puedes ver en la imagen a continuación.

La principal diferencia entre ellos es dónde se realiza la descompresión del bwce-runtime. En el caso del script por defecto, la descompresión se realiza en el proceso de inicio de la imagen, y en el reducedStartupTime esto se hace en la construcción de la imagen misma. Así que, puedes empezar a pensar que los predeterminados necesitan algún acceso de escritura ya que necesitan descomprimir el archivo dentro del contenedor, y eso es cierto.

Pero también, el reducedStartupTime requiere acceso de escritura para ejecutar la aplicación; se realizan varias actividades relacionadas con la descompresión del archivo EAR, la gestión del archivo de propiedades y actividades internas adicionales. Así que, no importa qué tipo de scripts estés usando, debes proporcionar una carpeta con acceso de escritura para realizar esta actividad.

Por defecto, todas estas actividades están limitadas a una sola carpeta. Si mantienes todo por defecto, esta es la carpeta /tmp, por lo que debes proporcionar un volumen para esa carpeta.

¿Cómo desplegar una aplicación TIBCO BWCE con el

Ahora, está claro que necesitas un volumen para la carpeta /tmp, y ahora necesitas definir el tipo de volumen que deseas usar para este. Como sabes, hay varios tipos de volúmenes que puedes determinar dependiendo de los requisitos que tengas.

En este caso, el único requisito es el acceso de escritura, pero no hay necesidad en cuanto a almacenamiento y persistencia, por lo que, en ese caso, podemos usar un modo emptyDir. El contenido de emptyDir, que se borra cuando se elimina un pod, es similar al comportamiento predeterminado pero permite permiso de escritura en su contenido.

Para mostrar cómo sería el YAML, usaremos el predeterminado que tenemos disponible en la documentación aquí:

apiVersion: v1
kind: Pod
metadata:
  name: bookstore-demo
  labels:
    app: bookstore-demo
spec:
  containers:
  - name: bookstore-demo
    image: bookstore-demo:2.4.4
    imagePullPolicy: Never
    envFrom:
    - configMapRef:
      name: name

Así que, cambiaremos eso para incluir el volumen, como puedes ver aquí:

apiVersion: v1
kind: Pod
metadata:
  name: bookstore-demo
  labels:
    app: bookstore-demo
spec:
  containers:
  - name: bookstore-demo
    image: bookstore-demo:2.4.4
    imagePullPolicy: Never
	securityContext:
		readOnlyRootFilesystem: true
    envFrom:
    - configMapRef:
      name: name
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

Los cambios son los siguientes:

Incluir la sección volumes con una única definición de volumen con el nombre de tmp con una definición de emptyDir.
Incluir una sección volumeMounts para el volumen tmp que se monta en la ruta /tmp para permitir escribir en esa ruta específica para habilitar también la descompresión del bwce-runtime así como todas las actividades adicionales que se requieren.
Para activar este comportamiento, incluye la bandera readOnlyRootFilesystem en la sección securityContext.

Conclusión

Incorporar un enfoque de ReadOnlyFileSystem en tus imágenes de TIBCO BWCE es una estrategia proactiva para fortalecer la postura de seguridad de tu aplicación. Al reducir el acceso de escritura innecesario y minimizar las posibles vías para acciones no autorizadas, estás dando un paso vital hacia la protección de tu entorno de contenedores.

Esta guía ha revelado los aspectos críticos de implementar tal medida de mejora de seguridad, guiándote a través del proceso con instrucciones claras y ejemplos prácticos. Con un enfoque en reducir vectores de ataque y reforzar el aislamiento, puedes desplegar con confianza tus aplicaciones TIBCO BWCE, sabiendo que has fortalecido su entorno de ejecución contra posibles amenazas.

Etiquetas:Security

How To Create a ReadOnlyFileSystem Image for TIBCO BWCE

por Alexandre Vazquez
2023-08-152024-09-29

This article will cover how to enhance the security of your TIBCO BWCE images by creating a ReadOnlyFileSystem Image for TIBCO BWCE. In previous articles, we have commented on the benefits that this kind of image provides several advantages in terms of security, focusing on aspects such as reducing the attack surface by limiting the kind of things any user can do, even if they gain access to running containers.

The same applies in case any malware your image can have will have limited the possible actions they can do without any write access to most of the container.

How ReadOnlyFileSystem affects a TIBCO BWCE image?

This has a clear impact as the TIBCO BWCE image is an image that needs to write in several folders as part of the expected behavior of the application. That’s mandatory and non-dependent on the scripts you used to build your image.

As you probably know, TIBCO BWCE ships two sets of scripts to build the Docker base image: the main ones and the ones included in the folder reducedStartupTime, as you can see in the GitHub page but also inside your docker folder in the TIBCO-HOME after the installation as you can see in the picture below.

The main difference between them is where the unzip of the bwce-runtime is made. In the case of the default script, the unzip is done in the startup process of the image, and in the reducedStartupTime this is done in the building of the image itself. So, you can start thinking that the default ones need some writing access as they need to unzip the file inside the container, and that’s true.

But also, the reduced startupTime requires writing access to run the application; several activities are done regarding unzipping the EAR file, managing the properties file, and additional internal activities. So, no matter what kind of scripts you’re using, you must provide a write-access folder to do this activity.

By default, all these activities are limited to a single folder. If you keep everything by default, this is the /tmp folder, so you must provide a volume for that folder.

How to deploy a TIBCO BWCE application with the

Now, that is clear that you need a volume for the /tmp folder, and now you need to define the kind of volume that you want to use for this one. As you know, there are several kinds of volumes that you can determine depending on the requirements that you have.

In this case, the only requirement is to write access, but there is no need regarding storage and persistency, so, in that case, we can use an emptyDir mode. emptyDir content, which is erased when a pod is removed, is similar to the default behavior but allows writing permission on its content.

To show how the YAML would like, we will use the default one that we have available in the documentation here:

apiVersion: v1
kind: Pod
metadata:
  name: bookstore-demo
  labels:
    app: bookstore-demo
spec:
  containers:
  - name: bookstore-demo
    image: bookstore-demo:2.4.4
    imagePullPolicy: Never
    envFrom:
    - configMapRef:
      name: name

So, we will change that to include the volume, as you can see here:

apiVersion: v1
kind: Pod
metadata:
  name: bookstore-demo
  labels:
    app: bookstore-demo
spec:
  containers:
  - name: bookstore-demo
    image: bookstore-demo:2.4.4
    imagePullPolicy: Never
	securityContext:
		readOnlyRootFilesystem: true
    envFrom:
    - configMapRef:
      name: name
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

The changes are the following:

Include the volumes section with a single volume definition with the name of tmp with an emptyDirdefinition.
Include a volumeMountssection for the tmpvolume that is mounted in the /tmp path to allow to write on that specific path to enable also the unzip of the bwce-runtime as well as all the additional activities that are required.
To trigger this behavior, include the readOnlyRootFilesystem flag in the securityContext section.

Conclusion

Incorporating a ReadOnlyFileSystem approach into your TIBCO BWCE images is a proactive strategy to fortify your application’s security posture. By curbing unnecessary write access and minimizing the potential avenues for unauthorized actions, you’re taking a vital step towards safeguarding your containerized environment.

This guide has unveiled the critical aspects of implementing such a security-enhancing measure, walking you through the process with clear instructions and practical examples. With a focus on reducing attack vectors and bolstering isolation, you can confidently deploy your TIBCO BWCE applications, knowing that you’ve fortified their runtime environment against potential threats.

Etiquetas:Kubernetes Security TIBCO TIBCO BusinessWorks