PostgreSQL Requirement for AME 4.0
Deployments using or planning to use Vulnerability Intelligence must have a PostgreSQL instance ready before upgrading to AME 4.0. Vulnerability Intelligence is moving from KV storage to PostgreSQL, which is required from AME 4.0 onward.
Before upgrading to AME 4.0
Provision and prepare a PostgreSQL instance for Vulnerability Intelligence data before upgrading. Include this requirement in upgrade planning so that the database is ready for AME 4.0.
The deprecated storage backend is identified in AME as KV-based Vulnerability Intelligence.
Connectivity from search heads
All search heads running AME must be able to connect to the PostgreSQL instance. In a search head cluster, this includes every member.
Before upgrading, verify the following from each search head:
- The PostgreSQL hostname resolves and the configured database port is reachable.
- Network routing and firewall rules allow connections from every search head to PostgreSQL.
- PostgreSQL accepts connections from every search head, including the required client authentication rules.
- Both PostgreSQL users described below can authenticate and connect to the AME database.
Splunk Cloud
Splunk Cloud deployments must also provide PostgreSQL connectivity from every search head running AME. Database provisioning and operation, including sizing, high availability, backups, and recovery, remain the responsibility of the users or their designated database provider.
Include the following in upgrade planning:
- Outbound access: Arrange outbound access from Splunk Cloud to the PostgreSQL destination addresses and configured database port. Where supported for the stack, outbound port rules can be managed through Splunk's Admin Config Service (ACS). See Configure outbound ports for Splunk Cloud Platform.
- Database access rules: Coordinate with the database or network administrator to allow the Splunk Cloud stack's applicable outbound source addresses through database firewall and authentication rules.
- Network path: Confirm the available connectivity options with Splunk for the specific stack, particularly for databases hosted on private networks. Opening an outbound port alone does not establish a route to a private database.
- Validation: Confirm hostname resolution, connectivity, and authentication from every relevant search head before upgrading. Include database failover destinations in connectivity planning.
Contact Splunk Support when the required network configuration cannot be completed through the available self-service controls. Allow time for connectivity changes and validation before the AME 4.0 upgrade.
Resources and sizing
Users are responsible for sizing the PostgreSQL instance for their workload. Hardware requirements can vary substantially between environments, so a development setup should not be used as a production sizing baseline.
Plan CPU, memory, storage capacity, and storage performance around:
- The number of realizations and their expected growth.
- Data retention periods and the amount of historical data retained.
- The volume and frequency of vulnerability ingestion and processing.
- The number, complexity, frequency, and concurrency of reports.
- Concurrent application activity across tenants and search heads.
Validate sizing with a representative workload, including peak ingestion and reporting periods. Monitor resource utilization, database growth, and processing and report runtimes, then adjust capacity as the workload changes. Allow capacity for migration, maintenance, and future growth.
High availability, backups, and recovery
Users are responsible for operating the PostgreSQL instance, including high availability, backups, recovery, monitoring, and maintenance. Include PostgreSQL in availability and disaster recovery planning for Vulnerability Intelligence.
- High availability: Choose and maintain a PostgreSQL deployment that meets the deployment’s availability requirements. Ensure every AME search head can reach the database endpoint after failover, and test failover and reconnection from all search heads.
- Backups: Define a backup schedule and retention policy that meet the organization’s data protection requirements. Protect backups and store them separately from the database instance.
- Recovery: Define acceptable data loss and recovery time, and regularly test restoring backups to verify that those targets can be met. High availability does not replace backups.
- Monitoring and maintenance: Monitor database availability, resource usage, free storage, and backup success. Plan database maintenance and updates around operational requirements.
Prepare and verify these arrangements before relying on PostgreSQL for production Vulnerability Intelligence data.
PostgreSQL users and database
AME uses two separate PostgreSQL users:
| User | Purpose | Required access |
|---|---|---|
Schema user (ame_schema_user) | Schema management, including creating and updating the AME schema and its database objects. | Connect to the database and create the schema and the objects needed by AME. |
Application user (ame_usage_user) | Application access to Vulnerability Intelligence data. | Connect to the database and access the AME schema and its data for application operations. |
The schema user must be able to create and manage the AME schema. Use separate credentials for schema management and application access.
Example database setup
The following example creates the two users and a dedicated database. Run it in psql as a PostgreSQL administrator with permission to create roles and databases. Replace the example names if needed; the \password commands prompt for each user's password.
CREATE ROLE ame_schema_user
LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION;
CREATE ROLE ame_usage_user
LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION;
\password ame_schema_user
\password ame_usage_user
CREATE DATABASE ame_database;
GRANT CONNECT, CREATE ON DATABASE ame_database TO ame_schema_user;
GRANT CONNECT ON DATABASE ame_database TO ame_usage_user;
This example prepares the database and grants database-level access. The application user also needs the appropriate permissions on the AME schema and its objects for application operations; CONNECT alone does not grant access to the data.
Migrate while running AME 4.0
After upgrading to AME 4.0, migrate existing Vulnerability Intelligence data from the legacy KV collections to PostgreSQL. The migration must be completed while running AME 4.0, before upgrading to AME 4.2.
AME 4.2 actively removes the legacy KV collections. Any data left in these collections will be permanently lost. Complete the migration while running AME 4.0; provisioning a PostgreSQL instance alone does not replace migrating your existing data.
Upgrade checklist
- Before AME 4.0: Provision and prepare PostgreSQL, create the schema and application users, and verify connectivity from every search head.
- Before production use: Validate sizing and establish high availability, backups, monitoring, and tested recovery procedures according to the organization’s requirements.
- While running AME 4.0: Complete the migration of Vulnerability Intelligence data to PostgreSQL.
- Before AME 4.2: Verify the migration is complete. AME 4.2 actively removes the legacy KV collections.
See Before Upgrading for the other checks to complete before updating AME.