OpenSearch provides a powerful Security plugin that delivers enterprise-grade protection for sensitive data, ensuring compliance with regulations like GDPR, HIPAA, and PCI while maintaining performance and usability.
OpenSearch Security is built on a four-layered security model combining encryption, authentication, access control, and audit logging to create multiple defense mechanisms protecting cluster data from unauthorized access and security threats.
The Four-Layered Security Model
OpenSearch implements defense-in-depth through four integrated security layers:
1. Encryption
Protects data both in transit and at rest from unauthorized access.
2. Authentication
Validates user and system identities before granting cluster access.
3. Authorization (Access Control)
Determines what authenticated users can do through role-based permissions.
4. Audit Logging
Tracks all cluster activities for compliance, monitoring, and security analysis.
These layers work together to ensure that only authorized users can access specific data, and all actions are logged for accountability.
Encryption in OpenSearch
Encryption in Transit (TLS/SSL)
OpenSearch uses Transport Layer Security (TLS) protocol to encrypt data moving to, from, and within the cluster through two distinct paths:
Client-to-Node Encryption (REST Layer) - Protects external requests from clients, applications, and OpenSearch Dashboards to cluster nodes.
Node-to-Node Encryption (Transport Layer) - Secures internal communication between cluster nodes, preventing tampering during data replication and cluster operations.
Both encryption layers use TLS 1.2 or higher, ensuring strong cryptographic protection against eavesdropping and man-in-the-middle attacks.
Encryption at Rest
Data stored on disk is protected through operating system-level encryption on each node, covering:
- Index data
- Log files
- Swap files
- Automated snapshots
- Application data
For Amazon OpenSearch Service, encryption at rest is provided automatically using AWS Key Management Service (KMS), encrypting data with the Advanced Encryption Standard (AES-256), securing indexes (including UltraWarm storage), logs, and automated snapshots.
TLS Configuration Best Practices
Replace Demo Certificates - The certificates generated by install_demo_configuration.sh are NOT suitable for production and must be replaced with certificates from your own Public Key Infrastructure (PKI).
Use Trusted Certificate Sources - Obtain certificates from:
- AWS Certificate Manager
- Let's Encrypt
- Enterprise PKI systems
- Tools like SearchGuard TLS Tool
Enable Both Encryption Layers - Configure plugins.security.ssl.http.enabled: true for REST layer encryption and ensure transport layer encryption is active.
Authentication Methods
OpenSearch Security supports multiple authentication mechanisms that can be chained together for enhanced security:
Internal User Database
Built-in user management with hashed passwords stored within OpenSearch. Suitable for smaller deployments or testing environments.
LDAP and Active Directory
Integrate with enterprise directory services for centralized user management and authentication.
SAML (Security Assertion Markup Language)
Enterprise single sign-on (SSO) protocol enabling users to authenticate through identity providers like Okta, Azure AD, or Google Workspace.
OpenID Connect (OIDC)
Modern authentication protocol built on OAuth 2.0, ideal for web and mobile applications.
JSON Web Tokens (JWT)
Token-based authentication for API access and microservices architectures.
TLS Client Certificates
Certificate-based authentication offers secure machine-to-machine authentication with low performance overhead, as authentication occurs at the TLS level. This method is particularly suitable for API integrations and automated systems.
Chaining Authentication Methods
Organizations commonly chain together more than one authentication method to support different use cases:
- Internal users for service accounts
- SAML/OIDC for human users accessing Dashboards
- Client certificates for API and machine-to-machine interactions
Authorization and Access Control
OpenSearch employs role-based access control (RBAC) with fine-grained permissions that can be assigned at multiple levels.
Role-Based Access Control (RBAC)
Users receive permissions indirectly through role assignments rather than direct permission grants. Roles define collections of permissions that align with job functions and responsibilities.
Fine-Grained Access Control (FGAC)
OpenSearch Security provides granular control at multiple abstraction levels:
Cluster-Level Permissions
Control cluster-wide operations like:
- Cluster health monitoring
- Snapshot creation and restoration
- Node management
- Plugin administration
Index-Level Permissions
Restrict access to specific indices with permissions for:
- Reading documents
- Writing and updating data
- Deleting documents
- Managing index settings
- Creating and deleting indices
Document-Level Security (DLS)
Controls which documents users can retrieve during read operations like search and get requests. DLS uses OpenSearch Query DSL to define accessible documents.
For example, a role might restrict access to only documents where a specific field matches a value:
{
"bool": {
"must": {
"match": {
"department": "Engineering"
}
}
}
}
Important limitation: DLS does NOT restrict write operations. Users with index write permissions can still modify documents hidden by DLS rules.
DLS Evaluation Modes
OpenSearch supports three DLS evaluation modes configured in opensearch.yml:
Lucene-level - Most efficient performance but doesn't support term-level lookup queries
Filter-level - Enables complex queries but limits operations to get, search, mget, and msearch
Adaptive (default) - Automatically switches between modes based on query requirements for optimal performance and functionality
Parameter Substitution in DLS
DLS supports dynamic variables like ${user.name} and ${user.roles} to enforce rules based on user properties, enabling flexible, user-specific filtering without hardcoding values.
Field-Level Security (FLS)
Restricts which fields within documents users can access. Sensitive fields can be completely hidden from unauthorized users.
Field Masking
Further extends FGAC by allowing certain roles to see sensitive fields in plain text while masking them for others. Field masking replaces the field's value with a cryptographic hash, enabling aggregation while preventing direct viewing.
Field Masking Limitations:
- Currently only available for string-based fields
- Masked fields cannot be searched (search terms within masked fields won't match)
- Known bug: FLS and field masking may not work as expected when combined with DLS
Role Management Best Practices
Minimize Role Complexity - Prioritize fewer, more intricate user roles over numerous simplistic roles, which enhances security and simplifies administration.
Regular Role Audits - Review role assignments periodically to ensure alignment with current job functions and the principle of least privilege.
Verify Access Restrictions - Test DLS, FLS, and field masking configurations using the _plugins/_security/authinfo endpoint to confirm restrictions work as expected.
Define Roles by Job Function - Create roles based on specific job responsibilities to minimize unnecessary privileges.
Multi-Tenancy
OpenSearch Dashboards multi-tenancy enables workspace isolation with role-based access control, allowing teams to share visualizations, dashboards, and saved objects safely.
How Multi-Tenancy Works
Multi-tenancy is enabled by default in OpenSearch Dashboards and provides:
Private Tenants - Personal workspace for individual users
Shared Tenants - Collaborative workspaces accessible to users with appropriate permissions
Global Tenant - Cluster-wide shared workspace
Tenant Access Control
Role configuration includes tenant permissions, specifying which tenants users can access and what actions they can perform (read-only or read-write).
Multi-Tenancy Best Practice
Disable Private Tenants When Unnecessary - If private tenants aren't needed, disable them by setting private_tenant_enabled: false in config.yml to reduce unnecessary index proliferation and simplify management.
Audit Logging and Compliance
Audit logs track all access to your OpenSearch cluster and are essential for compliance, security monitoring, and forensic analysis.
What Audit Logging Captures
OpenSearch audit logging records:
- Authentication events (successes and failures)
- User login attempts
- Search queries and requests to OpenSearch
- Index changes (creation, deletion, modifications)
- Document access and modifications
- Role and permission changes
- Configuration updates
Compliance Support
OpenSearch Security includes audit logging capabilities that support compliance with major regulatory frameworks:
GDPR - General Data Protection Regulation for data privacy
HIPAA - Health Insurance Portability and Accountability Act for healthcare data
PCI - Payment Card Industry Data Security Standard for payment data
SOX - Sarbanes-Oxley Act for financial reporting
ISO - International Organization for Standardization security standards
SOC 2 - Service Organization Control for service provider security
CCPA - California Consumer Privacy Act for consumer data protection
Third-party auditors assess Amazon OpenSearch Service as part of multiple AWS compliance programs, validating its suitability for regulated industries.
Audit Logging Configuration
By default, audit logging is disabled and must be explicitly enabled. Configuration best practices include:
Selective Logging - Disable unnecessary audit logs to prevent performance degradation and excessive storage consumption.
Recommended Settings:
- Set
audit.log_request_bodyto false (reduces logging overhead) - Disable
audit.resolve_bulk_requests(improves bulk operation performance) - Enable
compliance.write_log_diffs(tracks document changes for compliance) - Minimize watched fields and indices (focuses logging on critical data)
Immutable Audit Logs - Configure audit logs as immutable to prevent tampering, ensuring they can serve as reliable evidence for security investigations and compliance audits.
External Storage - Store audit logs in external systems (like Amazon S3 or dedicated SIEM platforms) for long-term retention and centralized security monitoring.
Security Configuration Management
Using securityadmin.sh
The securityadmin.sh command-line tool is the recommended method for managing OpenSearch security configurations, including:
- Roles and role mappings
- Internal users
- Action groups
- Tenant configurations
- Security plugin settings
Benefits of securityadmin.sh
Consistency - Ensures security configurations are applied consistently across all cluster nodes
Version Control - Security configurations can be stored as code and tracked in version control systems
Backup and Recovery - Use the -backup option before uploading modified configurations to create safety snapshots
Automation - Integrate security configuration changes into CI/CD pipelines
Initial Security Setup
Change Default Passwords Immediately - The default internal users (admin, logstash) must have their passwords changed before production use. Use the provided hash.sh tool to generate secure password hashes.
Best Practices for Securing OpenSearch
1. Certificate and Encryption
- Replace demo certificates with production certificates from trusted sources
- Enable encryption on both REST and transport layers
- Use TLS 1.2 or higher
- Regularly rotate certificates before expiration
- Store private keys securely with restricted access
2. Authentication Strategy
- Implement SSO (SAML or OpenID Connect) for OpenSearch Dashboards to delegate credential management and reduce password exposure
- Use client certificates for API and machine-to-machine authentication
- Chain multiple authentication methods for different use cases
- Enforce strong password policies for internal users
- Implement multi-factor authentication (MFA) when possible
3. Access Control
- Follow the principle of least privilege
- Create roles based on job functions rather than individual users
- Minimize the number of roles to simplify management
- Regularly audit role assignments
- Test DLS, FLS, and field masking rules thoroughly
- Document role purposes and permissions
4. Audit and Monitoring
- Enable audit logging for compliance requirements
- Configure selective logging to balance security visibility with performance
- Store audit logs externally for long-term retention
- Set up alerts for suspicious authentication patterns
- Review audit logs regularly for security anomalies
- Integrate with SIEM systems for centralized security monitoring
5. Security Administration
- Use
securityadmin.shfor all security configuration changes - Back up security configurations before modifications
- Store security configurations in version control
- Implement change management processes for security updates
- Test security changes in non-production environments first
- Document security architecture and procedures
6. Data Protection
- Classify data sensitivity levels
- Apply field masking for personally identifiable information (PII)
- Implement document-level security for multi-tenant scenarios
- Use field-level security to hide sensitive fields
- Encrypt snapshots containing sensitive data
- Regularly review data access patterns
7. Network Security
- Deploy OpenSearch within VPC or private networks when possible
- Use IP filtering to restrict access to known sources
- Implement network segmentation between cluster nodes and clients
- Use firewall rules to limit exposed ports
- Enable VPC endpoints for AWS OpenSearch Service
8. Operational Security
- Keep OpenSearch and the Security plugin updated with latest patches
- Monitor security advisories from OpenSearch project
- Implement automated security scanning in CI/CD pipelines
- Conduct regular security assessments and penetration testing
- Establish incident response procedures
- Train team members on security best practices
Common Security Use Cases
Enterprise Data Access Control
Organizations with multiple departments need to ensure employees only access data relevant to their roles. Implement:
- Document-level security to filter data by department
- Field-level security to hide sensitive fields (salaries, SSNs)
- Field masking to anonymize PII while enabling analytics
Compliance and Audit Requirements
Healthcare, finance, and other regulated industries require comprehensive audit trails. Configure:
- Immutable audit logging for all data access
- External audit log storage for long-term retention
- Compliance-focused logging (write diffs, access patterns)
- Regular audit log reviews and reporting
Multi-Tenant SaaS Applications
SaaS providers serving multiple customers on shared infrastructure must ensure data isolation:
- Document-level security with customer ID filtering
- OpenSearch Dashboards multi-tenancy for workspace isolation
- Role-based access control for customer administrators
- Field-level security for additional data protection
B2B Partner Data Sharing
Organizations sharing data with external partners need controlled access:
- SAML/OIDC authentication through partner identity providers
- Document-level security to expose only relevant data
- Time-limited access through role expiration
- Audit logging to track partner access patterns
API Security
Applications accessing OpenSearch through APIs require secure authentication:
- TLS client certificates for machine-to-machine authentication
- JSON Web Tokens (JWT) for API authentication
- IP-based access restrictions
- Rate limiting and API monitoring
Security Challenges and Considerations
Performance Impact
Security features like DLS, FLS, and audit logging can impact query performance. Balance security requirements with performance needs through:
- Selective audit logging (only critical events)
- Efficient DLS query design
- Performance testing with security enabled
- Monitoring query latency and resource usage
Configuration Complexity
OpenSearch Security offers extensive capabilities, which can be complex to configure correctly:
- Start with basic security and gradually add advanced features
- Thoroughly test security configurations before production deployment
- Document security architecture and role definitions
- Use infrastructure-as-code for consistent deployments
Known Limitations
DLS Write Protection - Document-level security doesn't restrict write operations, only reads
Field Masking Search - Masked fields cannot be searched
DLS/FLS/FMD Interaction - Known bug where field-level security and field masking may not work correctly with document-level security
Configuration Size - Maximum DLS configuration size is 1024 KB (1,048,404 characters)
Unicode Handling - Avoid Unicode special characters in DLS-controlled text fields, as they may cause unintended tokenization
Multiple Role Override Behavior
When users have multiple roles with different DLS configurations, queries combine with OR logic. However, if the plugins.security.dfm_empty_overrides_all setting is enabled, roles without DLS may override restrictive rules, potentially granting broader access than intended.
Frequently Asked Questions (FAQ)
What is the OpenSearch Security plugin?
The OpenSearch Security plugin is a comprehensive security solution that provides encryption, authentication, authorization, and audit logging for OpenSearch clusters. It's included with OpenSearch and implements fine-grained access control at cluster, index, document, and field levels.
Is OpenSearch secure by default?
OpenSearch includes the Security plugin, but it's not fully configured by default. For production deployments, you must replace demo certificates, configure authentication, define roles and permissions, and enable audit logging according to your security requirements.
What encryption does OpenSearch use?
OpenSearch uses TLS 1.2 or higher for encryption in transit (both client-to-node and node-to-node communication) and supports AES-256 encryption at rest through operating system-level encryption or AWS KMS for Amazon OpenSearch Service.
Can I integrate OpenSearch with Active Directory?
Yes, OpenSearch Security supports LDAP and Active Directory integration for authentication, enabling you to use existing enterprise directory services for user management and centralized access control.
What is fine-grained access control in OpenSearch?
Fine-grained access control (FGAC) provides granular permissions at multiple levels: cluster operations, specific indices, individual documents (document-level security), and specific fields within documents (field-level security and field masking).
How does document-level security work?
Document-level security (DLS) uses OpenSearch Query DSL to define which documents users can retrieve during read operations. It filters search results based on query criteria, ensuring users only see documents matching their access rules. However, DLS does not prevent write operations.
Does OpenSearch support compliance requirements?
Yes, OpenSearch Security includes audit logging and security controls that support compliance with GDPR, HIPAA, PCI, SOX, ISO, SOC 2, and CCPA. Third-party auditors regularly assess Amazon OpenSearch Service for compliance certification.
What authentication methods does OpenSearch support?
OpenSearch supports internal user database, LDAP, Active Directory, SAML, OpenID Connect, JSON Web Tokens (JWT), and TLS client certificates. Multiple methods can be chained together for different use cases.
How do I enable audit logging in OpenSearch?
Audit logging is disabled by default and must be enabled through the Security plugin configuration. Configure audit categories, log storage location, and settings using securityadmin.sh or the REST API. For Amazon OpenSearch Service, enable it through the AWS console or API.
What are the performance impacts of security features?
Security features like encryption, DLS, FLS, and audit logging can impact performance. The impact varies based on configuration complexity and usage patterns. Best practices include selective audit logging, efficient DLS queries, and performance testing with security enabled.
Can I use field masking for PII protection?
Yes, field masking is designed for protecting personally identifiable information (PII) by replacing field values with cryptographic hashes. This allows data aggregation and analytics while preventing direct viewing of sensitive data. However, masked fields cannot be searched.
What is the difference between field-level security and field masking?
Field-level security (FLS) completely hides fields from users, making them invisible in query results. Field masking shows the field but replaces its value with a cryptographic hash, allowing aggregation while protecting the actual value. FLS is stronger protection, while field masking enables limited analytics.
How do I manage security configurations across multiple environments?
Use the securityadmin.sh tool to manage security configurations as code, storing them in version control systems. This enables consistent deployments across development, staging, and production environments with automated CI/CD integration.
Should I use SAML or OpenID Connect for SSO?
Both SAML and OpenID Connect (OIDC) work well with OpenSearch. SAML is more common in traditional enterprise environments, while OIDC is favored for modern cloud-native applications. Choose based on your existing identity provider and architectural preferences.
What happens if I don't replace the demo certificates?
Demo certificates generated by install_demo_configuration.sh are publicly known and provide no real security. Using them in production exposes your cluster to unauthorized access and man-in-the-middle attacks. Always replace them with certificates from a trusted PKI.
