Crosscutting Concepts#
This chapter captures concepts that affect multiple parts of the architecture.
Domain Model#
The collection treats Exasol as the source of truth for users, roles, grants, authentication, authorization, and password state. An Ansible task supplies connection credentials and the desired administration state, while Exasol decides whether the authenticated account may perform the requested operation.
Configuration#
Connection credentials and user passwords are supplied through Ansible module parameters. The broader administration surface also carries role, grant-target, schema, and trusted-operator SQL inputs through module parameters, including the exasol_query and exasol_script interfaces. The user guide recommends storing secret values in Ansible Vault instead of plain playbook variables.
Password update behavior is controlled by update_password:
on_createsets a password only while creating a user.alwaysattempts a password update for an existing user.
Error Handling#
Authentication failures and module errors must be sanitized before they are returned to Ansible. Error messages must not include connection passwords, user passwords, or other secret values.
Logging and Observability#
Secret values are marked with Ansible no_log=True where module parameters carry credentials or passwords. The collection does not add telemetry and must not emit credential material through task output.
Security and Privacy#
The collection does not bypass Exasol’s authorization model. All operations execute using the permissions of the authenticated Exasol account.
The exasol_user module requires the connected account to already possess the corresponding administrative privileges. The collection does not implement privilege elevation.
Benefits:
Existing Exasol authorization rules remain authoritative.
Administrative boundaries are enforced by the database.
Playbooks cannot grant permissions unavailable to the authenticated account.
Credentials and passwords are treated as sensitive values:
login_passwordis marked withno_log=True.User passwords are marked with
no_log=True.Authentication failures must not expose credentials.
Error messages are sanitized before being returned to Ansible.
Exasol does not allow existing passwords to be retrieved or compared. This avoids exposing sensitive credential material through database introspection, but it intentionally limits idempotency for password updates. With update_password=always, an existing user password update can result in changed=true even when the submitted password value is unchanged.
Secret Redaction#
dsn~secret-redaction~1
The collection marks password-bearing parameters as no_log=True, redacts secret-bearing SQL before returning executed_queries, and sanitizes authentication failures before returning module results to Ansible.
Status: draft
Covers:
scn~password-not-exposed-in-failure-output~1scn~executed-queries-keep-object-names-but-redact-secrets~1
Needs: impl, utest
Password Update Semantics#
dsn~password-update-semantics~1
The collection models Exasol’s password comparison limitation explicitly: update_password=on_create avoids password updates for existing users, while update_password=always always sends a password update for existing users.
Status: draft
Covers:
scn~ansible-modules.exasol-user-leave-existing-user-unchanged~1scn~ansible-modules.exasol-user-update-existing-user-password~1
Needs: impl, utest
Encrypted Transport By Default#
dsn~encrypted-transport-by-default~2
Shared connection handling always enables pyexasol encryption. Certificate validation remains enabled by default. When operators disable CA validation for self-signed deployments, they must provide a certificate fingerprint so the connection still uses an explicit trust anchor instead of allowing an untrusted TLS session.
Status: draft
Covers:
scn~exasol-connections-use-encrypted-transport-by-default~2scn~fingerprint-pinning-keeps-trust-explicit~1scn~untrusted-tls-overrides-are-rejected~1
Needs: impl, utest
Canonical Schema Connection Parameter Mapping#
dsn~canonical-schema-connection-parameter~1
The shared connection argument specification exposes login_schema as the
canonical schema-selection parameter and maps its resolved value to
pyexasol’s schema keyword. login_db remains a deprecated alias. To match
Ansible alias resolution and retain compatibility for callers of the runtime
package, an explicitly supplied login_db value takes precedence if both
names are present.
Status: draft
Covers:
scn~ansible-playbook.exasol-query-login-schema-canonical~1
Needs: impl, utest