Security — General Standards
This page presents the main security standards used in TDP Kubernetes components.
It does not replace component-specific security pages. Use this page to understand general concepts and refer to the component page to apply the correct parameters, Secret names, values files, and complete examples.
How to use this page
Use this table as a quick map for where each security decision should be handled. It is not a rigid taxonomy: the same configuration can involve more than one layer.
| Question or decision | What to check | Where to go deeper |
|---|---|---|
| Sensitive credentials | Passwords, tokens, access keys, bind passwords, keystores, truststores, and references to existing Secrets | Credentials and Kubernetes Secrets; component security or integration page |
| User login | LDAP, Active Directory, SSO, internal account, and authentication scope | User authentication; component security page |
| Entry-point TLS | HTTPS through Ingress or Gateway API, hostname, certificate, and TLS Secret | TLS in Ingress or Gateway API; Ingress Configuration |
| Internal or integration TLS | LDAPS, secure database connection, S3, listeners, internal APIs, keystores, and truststores | TLS in the application; TLS in integrations; component security or integration page |
| Permissions and policies | Application authorization, Ranger policies, users, groups, and runtime policy enforcement | Authorization and policies; Security - Ranger when applicable |
| Network control | Allowed sources and destinations, cross-namespace traffic, and exposure of internal Services | NetworkPolicy and network access control; component page |
| Auditing | Access logs, authentication failures, sensitive operations, and operational traceability | Auditing and traceability; component page |
General principles
Before configuring security in any component, observe these principles:
- do not commit plain-text passwords in values files;
- prefer Kubernetes Secrets for sensitive credentials;
- use hostnames, certificates, and Secrets compatible with the real environment;
- validate whether the configuration belongs to the component, Ingress, or an external integration;
- consult the component-specific page before applying security parameters.
Credentials and Kubernetes Secrets
Sensitive credentials — such as database passwords, tokens, access keys, LDAP bind passwords, and keystore passwords — must be stored in Kubernetes Secrets.
TDP components generally allow referencing existing Secrets through parameters such as existingSecret, secretKeyRef, passwordSecret.name, or equivalent structures documented by the component.
Prefer this approach over providing passwords directly in component values.
Creating a Secret
kubectl -n <NAMESPACE> create secret generic <SECRET_NAME> --from-literal=<CONFIG_KEY>='<CONFIG_VALUE>'
Do not include plain-text passwords in values files committed to Git. Use Secret references or dedicated Secret management tools.
Advanced Secret management
In production environments, consider specialized tools for Secret management:
| Tool | Use |
|---|---|
| Sealed Secrets | Allows versioning encrypted Secrets in Git |
| External Secrets Operator | Syncs Secrets from external vaults |
| HashiCorp Vault | Centralizes credentials and access policies |
Credential rotation and revocation
Long-lived credentials need a defined rotation cycle. When rotating:
- Update or recreate the Kubernetes Secret with the new credentials.
- Restart pods that consume this Secret (environment variables or mounted files).
- Validate that applications are operating with the new credentials before discarding the old ones.
Practical revocation in Kubernetes is operational: remove or replace the Secret, restart workloads, and block network paths when necessary. Exposure time after compromise depends on how quickly Secrets are updated and pods are restarted.
Consult the component security page to learn which Secrets and pods must be restarted when rotating specific credentials.
User authentication
Some TDP components support authentication integrated with LDAP, Active Directory, SSO, or another external provider.
The configuration approach varies by component. It may involve:
- direct parameters in the component values;
- an additional values file applied as a Helm overlay;
- application-specific configuration;
- integration with an intermediary authentication provider;
- Kubernetes Secrets to store bind credentials or client secrets.
Therefore, there is no single LDAP or SSO model applicable to all components.
In components that use LDAP or AD as a lifecycle reference without server-side credential validation (e.g., without Kerberos), disabling an account in the directory does not automatically revoke already-distributed credentials. Revocation is operational: remove Secrets from workloads, restart them, and when necessary, block access via NetworkPolicy or network rules.
Consult the component security page to confirm:
- whether LDAP, AD, or SSO are supported;
- which parameters should be used;
- which Secrets must exist;
- whether there is a specific Helm overlay;
- whether authentication applies to the entire application or only to a web interface.
Helm overlay for authentication
Some components may provide additional values files for authentication, such as LDAP overlays.
When documented by the component, apply the overlay alongside the main file using -f <VALUES_FILE> and -f <LDAP_VALUES_FILE> in the component's Helm command.
Use overlays only when documented by the component. Not all components use this pattern.
TLS and certificates
TLS configuration can occur at different layers. These layers must not be confused.
TLS in Ingress or Gateway API
When a component is exposed via Ingress or Gateway API, TLS can be terminated at the Ingress Controller or Gateway.
This type of TLS protects external access to the service, for example:
https://ranger.empresa.com.br
The configuration typically involves a hostname, TLS Secret, certificate, and Ingress or Gateway API parameters.
For details, see Ingress Configuration.
Rate limiting in Ingress
In addition to TLS, configure request limits to protect externally exposed endpoints against abusive use. Ingress Controllers such as NGINX support specific annotations for this control:
annotations:
nginx.ingress.kubernetes.io/limit-rps: "100"
nginx.ingress.kubernetes.io/limit-connections: "10"
Consult the documentation of the Ingress Controller in use for available annotations. Appropriate values depend on the component and expected usage profile.
TLS in the application
Some components may also require TLS directly in the application, on listeners, internal APIs, or specific ports.
This type of configuration depends on the component and may involve:
- keystores;
- truststores;
- internal certificates;
- specific ports;
- component-specific parameters.
Consult the component security page to check whether it documents application-level TLS.
TLS in integrations
Some external integrations may also require TLS, for example:
- LDAPS for integration with a corporate directory;
- secure database connection;
- secure connection to S3-compatible storage;
- secure communication between components.
In these cases, the configuration may belong to the component security page or the corresponding integration page.
Authorization and policies
Authentication and authorization are different steps.
Authentication defines who the user is.
Authorization defines what that user can access or execute.
Some components have their own authorization. Others can be integrated with external authorization mechanisms, such as Apache Ranger, when that integration is planned and correctly configured.
When Ranger is used, two sides must be considered:
| Side | What it means |
|---|---|
| Ranger Admin | Registration of services, policies, users, and groups |
| Integrated component | Configuration required to query or enforce policies |
Registering a service in Ranger Admin does not, by itself, replace the component configuration for enforcing policies at runtime.
For details on policies, UserSync, LDAP, and Ranger integrations, see Security - Ranger.
Credentials for external integrations
Some components need to access external or complementary services, such as databases, object storage, S3-compatible services, or APIs.
These integrations typically require specific credentials, which must be stored in Kubernetes Secrets.
Generic example for S3-compatible credentials:
kubectl -n <NAMESPACE> create secret generic <S3_SECRET_NAME> --from-literal=access-key='<S3_ACCESS_KEY>' --from-literal=secret-key='<S3_SECRET_KEY>'
The method for referencing the Secret varies by component. Consult the component's integration or security page before applying the configuration.
For details on S3-compatible connections, see Integration Configuration.
NetworkPolicy and network access control
NetworkPolicy restricts incoming and outgoing traffic for pods in a Kubernetes cluster. In production environments, it is an essential layer of defense in depth, complementary to TLS and application authentication.
For TDP components, consider:
- Allow incoming traffic only from namespaces and ServiceAccounts that genuinely need the service.
- Block unnecessary outgoing traffic from pods with sensitive data.
- Treat internal Services (not exposed via Ingress) with the same attention as external services.
Enforcement of NetworkPolicy depends on the network plugin (CNI) in use in the cluster. Verify that the environment's CNI supports and enforces NetworkPolicies before relying on this control as the sole protection layer.
Consult the component security page for guidance on which ports and traffic sources should be allowed.
Audit and traceability
Enable audit logging in components that support this feature. Audit logs record accesses, authentication failures, and sensitive operations, and are essential for incident investigation and compliance.
Each TDP component documents, on its security page, whether and how audit logging can be enabled. By directing these logs to the environment's observability solution, it is possible to centralize alerts and analysis.
General monitoring principles:
- Monitor authentication failures — high volume may indicate an unauthorized access attempt.
- Monitor access to sensitive data outside normal operating hours.
- Retain audit logs for a period compatible with environment policies.
Next steps
To configure security for a specific component, access the corresponding security page in the Configuration index.
Use this page as a general reference to understand TDP Kubernetes security standards. Exact parameters must always be confirmed in the component-specific documentation.