diff --git a/README.md b/README.md index 269c62337..a77085982 100644 --- a/README.md +++ b/README.md @@ -87,7 +87,7 @@ Either just take a look at the [Rauthy Book](https://sebadob.github.io/rauthy/), the application yourself with docker on your localhost: ``` -docker run --rm -p 8080:8080 ghcr.io/sebadob/rauthy:0.16.0-lite +docker run --rm -p 8080:8080 ghcr.io/sebadob/rauthy:0.17.0-lite ``` **NOTE:** diff --git a/docs/getting_started/docker.html b/docs/getting_started/docker.html index 9f02334c0..10989b55b 100644 --- a/docs/getting_started/docker.html +++ b/docs/getting_started/docker.html @@ -7,7 +7,7 @@ - + @@ -152,7 +152,7 @@
6. Restrict DB files access even more
After rauthy has done the first start, you could harden the access rights of the SQLite files even more.
diff --git a/docs/getting_started/k8s.html b/docs/getting_started/k8s.html
index 7f39a45de..11eec9e24 100644
--- a/docs/getting_started/k8s.html
+++ b/docs/getting_started/k8s.html
@@ -7,7 +7,7 @@
-
+
@@ -206,17 +206,17 @@
Fast and efficient
The main goal was to provide an SSO solution like Keycloak and others while using a way lower footprint
-and being more efficient with resources. For instance, Rauthy can easily run a fully blown SSO provider on just a
+and being more efficient with resources. For instance, Rauthy can easily run a fully blown SSO provider on just a
Raspberry Pi. It makes extensive use of caching to be as fast as possible in cases where your database is further
-away or just a bit slower, because it is maybe running on an SBC from an SD card. Most things are even cached
+away or just a bit slower, because it is maybe running on an SBC from an SD card. Most things are even cached
for several hours (config options will come in the future) and special care has been taken into account in case of cache
eviction and invalidation.
A Rauthy deployment with the embedded SQLite, filled caches and a small set of clients and users configured typically
@@ -204,7 +204,7 @@
Highly Available
Even though it makes extensive use of caching, you can run it in HA mode. It uses its own embedded distributed HA cache
called redhac, which cares about cache eviction on remote hosts.
-You can choose between a SQLite for single instance deployments and a Postgres, if you need HA. MySQL support might
+You can choose between a SQLite for single instance deployments and a Postgres, if you need HA. MySQL support might
come in the future.
Client Branding
You have a simple way to create some kind of branding or stylized look for the Login page for each client.
@@ -212,7 +212,7 @@
rauthy
client, it will not only change the look for the Login
page, but also for the Account and Admin page.
Already in production
-Rauthy is already being used in production, and it works with all typical OIDC clients (so far). It was just not an
+Rauthy is already being used in production, and it works with all typical OIDC clients (so far). It was just not an
open source project for quite some time.
Keycloak was a rough inspiration in certain places and if something is working with Keycloak, it does with rauthy
too
(again, so far).
Currently missing features:
Rauthy Authenticator MFA App
Even though things like OTP codes will never be implemented, it is not set in stone yet that there will never be Rauthy's
-own Authenticator App, which then basically acts as a Webauthn Software Authenticator. There are already existing
+own Authenticator App, which then basically acts as a Webauthn Software Authenticator. There are already existing
solutions out there to serve this purpose.
OIDC Client
Rauthy will most probably have the option to be an OIDC Client itself as well. With this feature, you would be able
@@ -263,7 +263,7 @@
6. Restrict DB files access even more
After rauthy has done the first start, you could harden the access rights of the SQLite files even more.
@@ -427,17 +427,17 @@
The Admin UI provides a utility which helps you find the values for your deployment quickly. What and how to do is +
The Admin UI provides a utility which helps you find the values for your deployment quickly. What and how to do is described in the Admin UI itself, I just want to guide you to this utility especially, since it is an important step security wise.
When you are logged in to the Admin UI, please navigate to Config
-> Argon2 Parameters
to find your values.
@@ -801,7 +801,7 @@
MAX_HASH_THREADS
limits the maximum amount of parallel password hashes at the exact same time to never exceed system
memory while still allowing a good amount of memory.The rule is simple: Allow as many resources as possible for hashing to have the maximum amount of security, while +
The rule is simple: Allow as many resources as possible for hashing to have the maximum amount of security, while restricting it as much as necessary.
For smaller deployments, set MAX_HASH_THREADS=1
, which will technically allows only one user login at the exact same
time. This value makes an external rate limiting for the login obsolete (while you may add some for the others).
3. Set the ENC_KEY_ACTIVE
to the ID of your newly generated key
This will make sure, that all new encryptions will use the new key. If you do not care about removing the old keys, +
This will make sure, that all new encryptions will use the new key. If you do not care about removing the old keys,
because you maybe just want to rotate because its good practice, the secrets will migrate "by themselves" over time.
If Rauthy finds any secrets during its normal operation, that have been encrypted with an older key than the current
ENC_KEY_ACTIVE
, it will re-encrypt these secrets and update the values.
@@ -1026,7 +1026,7 @@
The easiest to do is to just set MIGRATE_DB_FROM
as an environmant variable, which is easier and quicker to remove
+
The easiest to do is to just set MIGRATE_DB_FROM
as an environmant variable, which is easier and quicker to remove
again afterwards.
Some values, like authentication codes for instance, do live in the cache only. Additionally, there might come an option with a future version which offers a special in-memory only mode in some situations.
Because of this, all instances create and share a single HA cache layer, which means at the same time, that you cannot -just scale up the replicas infinitely. The optimal amount of replicas for a HA mode would be 3, or if you need even higher +just scale up the replicas infinitely. The optimal amount of replicas for a HA mode would be 3, or if you need even higher resilience 5. More replicas should work just fine, but this has never been really tested and the performance will degrade at some point.
To achieve the HA caching layer embedded directly into the application, I created a library (or crate in Rust terms) @@ -1079,7 +1079,7 @@
This syncing of the cache is the reason why write performance will degrade, if you scale up too many replicas, which should -not really be necessary anyway. The best HA performance will be achieved with 3 replicas and then scaling up the +not really be necessary anyway. The best HA performance will be achieved with 3 replicas and then scaling up the resources for each pod before adding more replicas.
The way to configure the HA_MODE
is optimized for a Kubernetes deployment but may seem a bit odd at the same time,
@@ -1087,7 +1087,7 @@
HA_MODE
The first one is easy, just set HA_MODE=true
HA_HOSTS
The HA_HOSTS
is working in a way, that it is really easy inside Kubernetes to configure it, as long as a
+
The HA_HOSTS
is working in a way, that it is really easy inside Kubernetes to configure it, as long as a
StatefulSet is used for the deployment.
The way a cache node finds its members is by the HA_HOSTS
and its own HOSTNAME
.
In the HA_HOSTS
, add every cache member. For instance, if you want to use 3 replicas in HA mode which are running
@@ -1155,7 +1155,7 @@
As mentioned, the tools are very basic. If you for instance type in a bad password during CA / intermediate generation,
they will just throw an error, and you need to clean up again. They should only get you started and be used for testing.
-There are a lot of good tools out there which can get you started with TLS and there is no real benefit in creating
+There are a lot of good tools out there which can get you started with TLS and there is no real benefit in creating
just another one that does the same stuff.
The scripts can be found here (TODO add link to tools).
You need to have openssl
and a BASH shell available on your system. They have not been tested with Windows.
The TLS configuration for the REST API is much simpler.
-By default, rauthy will expect a certificate and a key file in /app/tls/tls.key
and /app/tls/tls.crt
, which is the
+By default, rauthy will expect a certificate and a key file in /app/tls/tls.key
and /app/tls/tls.crt
, which is the
default naming for a Kubernetes TLS secret. The expected format is PEM, but you could provide the key in DER format too,
if you rename the file-ending to *.der
.
You can change the default path for the files with the config variables TLS_CERT
and TLS_KEY
.