Security design and risk mitigation

Talend Management Console and Dynamic Engine solution incorporates a security-specific design to address common risks associated with using any cloud solution.

Network communications:
1. All communications across different parts of Talend Management Console and Dynamic Engine go through HTTPS.
2. All users are required to access the Dynamic Engine services exclusively through Talend Management Console and its API endpoints.
3. Talend processing services deployed in the Kubernetes clusters are directly or indirectly connected to Talend Cloud through ActiveMQ over HTTPS. Talend Cloud services are designed with request isolation in mind; therefore, a request targeting a given Dynamic Engine environment cannot reach other Dynamic Engine environments.
4. For air-gapped environments where outbound traffic must be controlled, configure Dynamic Engine services to route all HTTP/HTTPS requests through a proxy server. For details, see Using an HTTP proxy for Dynamic Engine services in air-gapped environments.
Authentication and authorization:
A Talend Cloud user must authenticate to Talend Management Console and in the meantime, obtain the Engines - Manage permission (ID: TMC_CLUSTER_MANAGEMENT) to manage Dynamic Engines. This user's login activities are recorded in Talend Cloud logs.
Artifact integrity and authenticity:
1. Validate the authenticity and integrity of Dynamic Engine artifacts (images and Helm charts) by verifying their digital signatures before deployment. For details, see Security option: Verifying Dynamic Engine artifact signatures.
2. Verify data integration Job artifacts signed with your organization's certificate authority by deploying a custom Java keystore for your Dynamic Engine environment. For details, see Security with a custom keystore for Dynamic Engine environment services.
Protection against DoS attacks:
You can use the jobLimits property to limit the Job size for deployment and execution in each Dynamic Engine environment. Any artifact that exceeds this limit is deleted to protect against DoS attacks.
The jobLimits property is added in the ConfigMap called global-configuration of each Dynamic Engine environment and accepts the format in the following example:
```
"jobLimits": {
  "maxZipNameLength": 240,
  "maxZippedEntries": 2048,
  "maxUnzippedSize": 1000000000,
  "maxUnzippedFolderNameLength": 240,
  "maxUnzippedFileNameLength": 240,
  "maxZipDepth": 64
}
```
Among the fields,
- maxUnzippedSize: maximum size of the uncompressed zip file in bytes.
- maxZippedEntries: maximum number of files and directories in the zip file.
- maxZipDepth: maximum nesting level of directories in each artifact zip.
For instructions on how to apply Job size limits with Helm deployments, see Configuring Job size limits for Dynamic Engine environments.
Information noteAttention: This protection applies only to data integration Jobs, not to Data Services and Routes.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!

Leave your feedback here