At some point, Firefly III added an `ALLOW_WEBHOOKS` option. It's set
to `false` by default, but it didn't seem to have any affect on
_running_ webhooks, only visiting the webhooks configuraiton page. Now,
that seems to have changed, and the setting needs to be enabled in order
for the webhooks to run.
I'm not sure why `disableNameSuffixHash` was set on the ConfigMap
generator. It shouldn't be, so that Kustomize can ensure the Pod is
restarted when the contents of the ConfigMap change.
This network policy blocks all outbound communication except to the
designated internal services. This will help prevent any data
exfiltration in the unlikely event the Firefly were to be compromised.
Although Firefly III works on a Raspberry Pi, a few things are pretty
slow. Notably, the search feature takes a really long time to return
any results, which is particularly annoying when trying to add a receipt
via the Receipts app. Adding a node affinity rule to prefer running on
an x86_64 machine will ensure that it runs fast whenever possible, but
can fall back to running on a Rasperry Pi if necessary.
Since the new database server outside the Kubernetes cluster, created
for Authelia, was seeded from a backup of the in-cluster server, it
already contained the data from Firefly-III as well. Thus, we can
switch Firefly-III to using it, too.
The documentation for Firefly-III does not mention anything about how
to configure it to use certificate-based authentication for PostgreSQL,
as is required by the new server. Fortunately, it ultimately uses
_libpq_, so the standard `PG...` environment variables work fine. We
just need a certificate issued by the _postgresql-ca_ ClusterIssuer and
the _DCH Root CA_ certificate mounted in the Firefly-III container.
The Firefly III Data Importer does not allow transaction imports by
unattended HTTP requests by default, but this can be enabled with the
`CAN_POST_FILES` environment variable. Additionally, an
`AUTO_IMPORT_SECRET` environment variable must be set containing a
shared "secret" value which must be provided in the querystring of
autoimport requests.
Since we have the Data Importer protected by Authelia, we need to make
some additional changes to the Ingress to allow unattended
authentication. Authelia supports passing the username and password of
an authorized user in the `Proxy-Authorization` HTTP request header. If
this header is valid, it will allow the request through. Unfortunately,
many HTTP clients will not set this header unless they are also
configured to explicitly connect via a forward proxy. To simplify
usage of such clients, we can configure nginx to copy the value of the
normal `Authorization` header into `Proxy-Authorization`, thus allowing
clients to use simple HTTP Basic authentication, even though the Data
Importer doesn't actually support it.
[Firefly III][0] is a free and open source, web-based personal finance
management application. It features a double-entry bookkeeping system
for tracking transactions, plus other classification options like
budgets, categories, and tags. It has a rule engine that can
automatically manipulate transactions, plus several other really useful
features.
The application itself is mostly standard browser-based GUI written in
PHP. There is an official container image, though it is not
particularly well designed and must be run as root (it does drop
privileges before launching the actual application, thankfully). I may
decide to create a better image later.
Along with the main application, there is a separate tool for importing
transactions from a CSV file. Its design is rather interesting: though
it is a web-based application, it does not have any authentication or
user management, but uses a user API key to access the main Firefly III
application. This effectively requires us to have one instance of the
importer per user. While not ideal, it isn't particularly problematic
since there are only two of us (and Tabitha may not even end up using
it; she seems to like YNAB).
[0]: https://www.firefly-iii.org/
