PRE-RELEASE INFORMATION: SUBJECT TO CHANGE

Deployment

Housecarl AuthZ is tested as a Kubernetes application connecting to PostgreSQL version 17 or higher, with a Kubernetes nginx Ingress controller.

Deployment Quickstart:

  • configure the PostgreSQL connection string in the Helm values.yaml file
  • Adjust the Ingress configuration to your cluster’s standard in the values.yaml
  • helm install -n housecarl-authz housecarl-authz
  • Check the system log for the initial root password
  • Change the password: run housecarl-admin user set-password root $new_secret_password, passing in the PostgreSQL connection string.
  • housectl config login root root $new_secret_password
  • # at this point you can create users, set up new tenants, new domains, configure policies, etc.

Deployment Recommendations

Linux Kubernetes is the supported deployment platform for Housecarl. As noted above, we offer a Helm chart as part of the package, along with a Docker file.

For production cloud deployments, we recommend using AWS RDS or similar managed PostgreSQL databases in a live multi-AZ failover configuration to minimize downtime, along with routine backup procedures. While we have made every effort to ensure our SQL queries are fast and the indexes on the tables are appropriate, a production deployment should also include appropriate monitoring and alerting on database load and other key metrics.

For testing deployments, we use the Bitnami Postgres Helm chart to deploy a PostgreSQL server in the Kubernetes namespace; it is a space-efficient means of rapid testing.

Topologies

Two essential topological approaches can be used - service-based or centralized. Service-based approaches split the policies service-by-service. This will be, approximately, 1 Housecarl AuthZ deployment per service. This reduces issues with shared configuration deployment bringing your system down on misconfiguration, at the cost of not having a single source of truth for your permissions. Conversely, you can deploy Housecarl AuthZ as a centralized service and have a single source of truth, at the cost of higher risk for deployment failure.

Other approaches are plausible as well, but would be associated with your enterprise configuration.

Alternative approaches.

Housecarl AuthZ can, in all likelihood, be deployed in a multitude of (typically) untested or unsupported configurations. Plausible configurations that have been looked at to date include -

  • AWS Lambda or GCP Cloud Run.
    • Care will need to be taken to ensure the database is migrated reliably and the 'cold-boot' phase is run on upgrade.
    • An "all-in-one" faas mode is supplied in the housecarl-server binary, but it bundles both the migration and cold-boot phases as well and as such is a bit slow to boot. It thus will not be rapidly reactive under load. Supporting services such as audit would remain separate.
  • Traditional Linux VMs.
    • The Housecarl binary can be run on Linux directly.
    • SystemD or SysV init files are not supplied.
  • docker-compose
    • This is useful for local testing: production deployment with docker-compose should be done with care.

Other approaches such as Heroku, AWS ECS, etc, are feasible but have not been looked at.

Please contact sales@housecarl.cloud to discuss support for these non-Kubernetes configurations.