Learn Pentaho - Security, Authentication & Authorization

#Introduction

A data platform handles a company's most valuable assets: its data itself. This episode covers Pentaho security — protecting communication with SSL/TLS, managing identity through internal or LDAP/Active Directory authentication, limiting access with role-based access control, and protecting data source credentials from exposure.

After this episode, you'll be able to tell essential security hardening from the excessive kind, and know which steps must be done before the server is accessed by more than one person.

#Securing Communication with SSL/TLS

By default, the Pentaho Server runs over plain HTTP — all traffic, including passwords, can be read on the network. For production, you must enable SSL/TLS so communication is encrypted.

The general steps:

1. Prepare a certificate — from a public CA, or self-signed for the lab.
2. Import the certificate into a Java keystore with keytool.
3. Configure Tomcat (Pentaho's built-in web server) to use that keystore and listen on an HTTPS port.

Creating a self-signed keystore for the lab can be done with keytool:

keytool -genkeypair -alias pentaho \
  -keyalg RSA -keysize 2048 \
  -keystore pentaho.keystore \
  -storepass changeit \
  -validity 365

After the configuration is done, access the server via https:// and make sure there's no certificate warning in the browser.

#Authentication: Internal, LDAP, and Active Directory

Authentication answers the question "who are you?". Pentaho supports several identity sources:

• Internal users: users and passwords managed directly in Pentaho (configuration files on the server). Enough for small teams.
• LDAP: connecting authentication to an LDAP directory server like OpenLDAP.
• Active Directory: AD integration for Windows organizations, allowing login with existing accounts.

LDAP/AD configuration is done through the Spring Security files on the server. Here's a look at the file that's usually changed:

tomcat/webapps/pentaho/WEB-INF/
└── applicationContext-security-ldap.properties

With LDAP/AD, you also get added value: accounts are managed in one place, passwords are centrally managed, and policies like lockout apply across the organization.

#Role-Based Access Control for Content and Jobs

Authorization answers "what are you allowed to do?". Pentaho implements RBAC through a combination of users, roles, and permissions:

• Role: for example Admin, Developer, Business Analyst, Scheduler, Read-only.
• Permission on repository objects: Read, Write, Execute, Schedule, Delete.
• Folder restrictions: rights can be set per folder, so specific teams only see their part of the repository.

The principle followed: least privilege — give the minimum rights the job needs. Analyst teams only need Read and Execute; only developers have Write and Schedule on specific jobs.

A real-world practice example: user siti from the sales team only has Read access to the sales report folder and can't see the HR data folder. This is set once in administration, then applies consistently.

#Securing Data Source Credentials

Database credentials inside transformations are a prime target. Several layers of protection you should apply:

• Don't hardcode: never write database passwords directly in the Table input or Table output step. Use variables.
• Protect the kettle.properties file: make sure this file can only be read by the user running PDI, not everyone on the machine.
• Server-side credentials: when running on the Pentaho Server, use connections managed in the repository — credentials aren't visible to unauthorized users.
• File permission control: restrict access to configuration files with strict filesystem permissions.

Using variables in connections from the start (episode 9) automatically prevents credentials from being written into the .ktr files that go into Git. This is one reason why the variable substitution habit is so important.

#Security Habits for Operations

Besides configuration, there are operational habits that keep security standing:

• Change default passwords immediately after installation (admin and other built-in users).
• Limit server exposure: don't expose the Pentaho Server directly to the internet; put it on an internal network or behind a reverse proxy.
• Separate environments: dev, staging, and production must not share the same credentials.
• Update regularly: patch Pentaho and JDK to close known vulnerabilities.
• Access logging: enable login auditing and monitor suspicious activity.

All of these complement the monitoring topics in episode 13 and the runbook in episode 19, forming a robust operational whole.

#Conclusion

In episode 12 you secured the platform: protecting communication with SSL/TLS, configuring internal, LDAP, and Active Directory authentication, implementing RBAC for content and jobs, and protecting data source credentials.

The key takeaways:

• SSL/TLS is mandatory for production; self-signed is only for the lab.
• Centralized authentication (LDAP/AD) makes organizational identity management easier.
• Apply least privilege: roles and permissions set per folder and object.
• Data source credentials are stored via variables and server connections, not hardcoded in files.

In episode 13, we keep the platform healthy: monitoring & observability — monitoring job executions, analyzing logs and capturing errors, monitoring resource usage and throughput, and integrating with external monitoring tools.