PostgreSQL Anonymizer Extension (anon) on Flexible Server - Configuration Limitations and Unexpected Behavior

Question

Hi,

We're implementing data anonymization on Azure Database for PostgreSQL Flexible Server using the anon extension (v1.3.2) and have encountered several limitations that are blocking our implementation. I'd appreciate clarification on whether these are expected behaviors or configuration issues on our side.

Environment:

• Azure Database for PostgreSQL Flexible Server
• PostgreSQL version: 13
• Extension: anon v1.3.2
• Use case: Anonymizing PII data on a replica database for BI/analytics access

Issues encountered:

1. Cannot configure database-level anon parameters

We cannot enable Transparent Dynamic Masking at the database level:

ALTER DATABASE mydb SET anon.transparent_dynamic_masking = true;

-- ERROR: permission denied to set parameter "anon.transparent_dynamic_masking"

The anon.* parameters appear read-only in the Azure Portal server parameters. This forces us to call anon.start_dynamic_masking() per session, which is not viable for BI tools like Apache Superset.

There is no update for several months now. Is this planned? https://techcommunity.microsoft.com/blog/ModernizationBestPracticesBlog/implementing-oracle-data-masking-capabilities-in-azure-postgresql--flexible-serv/4255450

2. Custom schemas are being dropped unexpectedly

Following the anon documentation, we created a trusted schema for custom masking functions:

CREATE SCHEMA custom_masks;

SECURITY LABEL FOR anon ON SCHEMA custom_masks IS 'TRUSTED';

CREATE FUNCTION custom_masks.my_function(...) ...

This schema has been dropped 4 times during our session without any explicit DROP command from our side. The server did not restart (verified via pg_postmaster_start_time()). We cannot identify what is removing it.

3. Cannot create functions in the anon schema

CREATE FUNCTION anon.my_custom_function(...) ...

-- ERROR: permission denied for schema anon

This is understandable as it's an extension schema, but combined with issue #2, it leaves us with only the public schema as a stable location for custom masking functions, which is not best practice.

4. Extension version

Is there a timeline for anon v2.0+ on Flexible Server? Version 2.3 includes "Replica Masking" which would solve our use case natively.
https://www.postgresql.org/about/news/postgresql-anonymizer-23-replica-masking-3099/

Questions:

1. Is there a way to set anon.transparent_dynamic_masking at the database or server level?
2. What could be causing our custom schema to be dropped? Are there Azure maintenance processes that affect user-created schemas?
3. Is placing custom masking functions in the public schema supported for use with anon security labels?
4. What is the roadmap for anon extension updates on Flexible Server?

Any guidance would be appreciated. We want to ensure we're implementing this correctly and not fighting against platform limitations.

Thank you

Answer 1

1. Setting anon.transparent_dynamic_masking: Currently, the anon parameters are read-only in Azure Database for PostgreSQL Flexible Server. This means you cannot set anon.transparent_dynamic_masking at the database or server level, which aligns with the behavior you're experiencing. You will need to call anon.start_dynamic_masking() per session as a workaround.
2. Dropping of Custom Schemas: The unexpected dropping of your custom schema could be due to Azure maintenance processes or other automated tasks that might be affecting user-created schemas. Unfortunately, there is no specific documentation detailing these processes, so it may require further investigation or support from Azure to determine the exact cause.
3. Using the Public Schema for Custom Functions: Placing custom masking functions in the public schema is technically supported, but it is not considered best practice. It is advisable to keep custom functions in a dedicated schema to maintain organization and security. However, given the current limitations, this may be your only option.
4. Roadmap for anon Extension Updates: There is no specific timeline provided for updates to the anon extension on Flexible Server. For the latest features and updates, including version 2.0+, you may need to keep an eye on official announcements from Microsoft or the PostgreSQL community.

In summary, the limitations you are encountering are expected behaviors of the Azure Database for PostgreSQL Flexible Server and the anon extension. For further assistance, consider reaching out to Azure support for more detailed insights into your specific issues.

---

References:

• Secure your Azure Database for PostgreSQL Server
• Frequently asked questions about elastic clusters in Azure Database for PostgreSQL

Answer 2

Hi Harry Georgilas,

1.Restrictions on anon.transparent_dynamic_masking and Other anon.* Parameters:

Intentional restriction by design on Azure Database for PostgreSQL Flexible Server to block GUC change from porta, but regarding to session/ database level the should be able to. That has been removed in late versions (2.4+), they can set it at database level too, let the customer aware that PG 13 has reached the community retirement date, and the extended support will end by April 1_st_ 2026, so we recommend the customer to move to higher versions like PG16 to have a complete support and also to protect from any unexpected behaviour or bugs.

postgres=> alter database postgres set anon.transparent_dynamic_masking = on;

ALTER DATABASE

postgres=>

2.What could be causing our custom schema to be dropped? Are there Azure maintenance processes that affect user-created schemas?

This does not sound like expected behaviour and could represent a misconfiguration or some process interference that dropped the schema, to be sure and understand more, we can suggest the customer to:

• Enable detailed logging in Azure (set log_min_duration_statement to 0 and enable pgaudit and repro the issue.
• monitor via Azure Log Analytics) to capture the drop events and see from where it is coming from.
• Turn off the auditing if not needed.

3.Is placing custom masking functions in the public schema supported for use with anon security labels?

The inability to create functions in the anon schema is by design and expected—extension schemas are protected to prevent modifications that could break the extension or introduce security risks. This is consistent across all of our versions

Public Schema Support: Yes, placing custom masking functions in the public schema is officially supported for use with anon's security labels (e.g., SECURITY LABEL FOR anon ON FUNCTION public.my_custom_function IS 'MASKED'. It's not ideal from a best-practice standpoint (as public can become cluttered), but it's should work without issues.

Recommended Alternative Schema Pattern for Azure: Instead of public, create a dedicated schema like masking_utils. Tag it as 'TRUSTED' per anon's docs. If drops persist (hopefully it is not), consider check the log analytics to see who did that, and use the below alternatives:

• Storing functions in a schema owned by a role with limited privileges.
• Using PostgreSQL's search_path to isolate them without relying on custom schemas.

4.What is the roadmap for anon extension updates on Flexible Server?

The latest version 2.4.0 will be available in the next Dataplane deployment (M54) part of our servers have it, the rest will be early in Jan 26, for newly created servers, they should be able to see that extension with latest version.

Please let us know if you have any questions and concerns.