mart-w/kanidm
1
0
Fork 0
mirror of https://github.com/kanidm/kanidm.git synced 2025-02-24 04:57:00 +01:00
Code Issues Actions 10 Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse source 
Co-authored-by: Charelle Collett <Charcol@users.noreply.github.com>
This commit is contained in:
Firstyear 2020-08-08 13:23:16 +10:00 committed by Firstyear
parent 351727ad02
commit 15fc1d9f50
1 changed files with 18 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
designs/resource_limits.rst
View file

@ -1,12 +1,12 @@
Resource Limits Resource Limits
--------------- ---------------
As a piece of security sensitive software, kanidm must be "available" (as defined by As security sensitive software, kanidm must be "available" (as defined by
integrity, availability and confidentiality). This means that as a service we must confidentiality, integrity, and availability). This means that as a service we must
be able to handle a large volume of potentially malicous traffic, and still able be able to handle a large volume of potentially malicous traffic, and still able
to serve legitimate requests without fault or failure. to serve legitimate requests without fault or failure.
To achieve this, the resources of the server must be managed and distributed so allow To achieve this, the resources of the server must be managed and distributed to allow
potentially thousands of operations per second, while preventing exhaustion of those potentially thousands of operations per second, while preventing exhaustion of those
resources. resources.
@ -19,9 +19,9 @@ someone's email address in a corporate directory context.
Each operation requires resources to complete individually, but many operations Each operation requires resources to complete individually, but many operations
can be processed in parallel. can be processed in parallel.
For a resource exhaustion to occur, this would be due to input from a client Resource exhaustion occurs when input from a client consumes more resources
that consumes resources. This means the attack surface is any possible input than the server can provide. This means the attack surface is any possible input
and how the server interprets and processes that. In kanidm this could be and how the server interprets and processes that input. In kanidm this could be
a search filter for example - the query may be small, but it could be expensive a search filter for example - the query may be small, but it could be expensive
to compute. to compute.
@ -57,20 +57,20 @@ These necesitate the following limits:
Memory (RAM) Capacity Memory (RAM) Capacity
===================== =====================
A system has finite ram amounts which must be shared between all CPU's of the system. A system has finite amounts of RAM which must be shared between all CPUs of the system.
Effective use of that RAM improves the speed of all operations, meaning that as a shared Effective use of that RAM improves the speed of all operations, meaning that as a shared
resource it can not be monopolised by a single operation. resource it can not be monopolised by a single operation.
Each operation can be assumed to have access to RAM/N CPUS of ram. If an operation tempororily Each operation can be assumed to have access to RAM/n CPUs of RAM. If an operation temporarily
exceeds this, the impact is minimal, but continued use of a single CPU using a high capacity exceeds this, the impact is minimal, but continued use of a single CPU using a high capacity
of RAM can prevent other operations functioning. Additionally, past operations can impact of RAM can prevent other operations functioning. Additionally, past operations can impact
the content of RAM though cache invalidation attacks for example. the content of RAM though cache invalidation attacks.
To prevent overuse of RAM, the following must be considered To prevent overuse of RAM, the following must be considered
* Cache strategies to prevent invalidation attacks (done, ARC + ahash). * Cache strategies to prevent invalidation attacks (done, ARC + ahash).
* Limit the amount of entries that can be dirtied in a write operation * Limit the amount of entries that can be dirtied in a write operation
* Limit the numer of entries that can be filter-tested in partial index queries * Limit the number of entries that can be filter-tested in partial index queries
* Limit the amount of entries that can be loaded for a read operation * Limit the amount of entries that can be loaded for a read operation
* Limit the size of cache to allow room for operation result sets (done) * Limit the size of cache to allow room for operation result sets (done)
* Cache closer to the application rather than using db/vfs caches (done) * Cache closer to the application rather than using db/vfs caches (done)
@ -90,7 +90,7 @@ or to not issue or allow requests that would generate large amounts of IOPS.
* Limit the number of large items that can be loaded in an operation IE partial index scans, full table scans * Limit the number of large items that can be loaded in an operation IE partial index scans, full table scans
* Limit the size of write operations. * Limit the size of write operations.
Disk/Capacity Disk Capacity
============= =============
If the storage capacity is exceeded this can cause the system to panic or stop, which would act If the storage capacity is exceeded this can cause the system to panic or stop, which would act
@ -99,14 +99,14 @@ the worst case, data corruption. This means that during write operations, the am
must be limited. must be limited.
* Limit the number of entries that can be dirtied in an operation * Limit the number of entries that can be dirtied in an operation
* Limit the maximum number of multivalue attributes on an entrie to prevent the entry growing over-size * Limit the maximum number of multivalue attributes on an entry to prevent the entry growing over-size
* Entry maximum size limits * Entry maximum size limits
* Limit the amount of churn in an entry to prevent changelog growth * Limit the amount of churn in an entry to prevent excessive changelog growth
Stack Limits Stack Limits
============ ============
As some operations are recursive, the stack depth becomes a concern as when exceeded, the system As some operations are recursive, the stack depth becomes a concern because when the stack depth is exceeded, the system
can crash or panic. The major recursive structure is filters and how we process queries. can crash or panic. The major recursive structure is filters and how we process queries.
To prevent stack exhaustion: To prevent stack exhaustion:
@ -131,7 +131,7 @@ Search Limits:
* Prevent searching on terms that do not exist (done, filter schema validation) * Prevent searching on terms that do not exist (done, filter schema validation)
* Deny unindexed searches * Deny unindexed searches
* Limit the amount of entries that can be loaded for a read operation * Limit the amount of entries that can be loaded for a read operation
* Limit the numer of entries that can be filter-tested in partial index queries * Limit the number of entries that can be filter-tested in partial index queries
* Limit on the number of entries that can be loaded from a search * Limit on the number of entries that can be loaded from a search
* Limit the depth of nesting in a search query (filter). * Limit the depth of nesting in a search query (filter).
* Reduce the size of allowed queries to prevent complex index access patterns * Reduce the size of allowed queries to prevent complex index access patterns
@ -151,9 +151,9 @@ Writes:
* Limit the number of entries that can be dirtied in an operation * Limit the number of entries that can be dirtied in an operation
* Limit the maximum number of multivalue attributes on an entry to prevent the entry growing over-size * Limit the maximum number of multivalue attributes on an entry to prevent the entry growing over-size
* Entry maximum size limits * Entry maximum size limits
* Limit the amount of churn in an entry to prevent changelog growth * Limit the amount of churn in an entry to prevent excessive changelog growth
These limits should be applied per-account to allow some accounts to over-ride these. For example These limits should be applied per-account to allow some accounts to override these, for example
an application which needs to bulk update accounts, or admins who need to perform audits. an application which needs to bulk update accounts, or admins who need to perform audits.
The system maintains a default set of limits. Accounts can then have resource groups associated. The system maintains a default set of limits. Accounts can then have resource groups associated.
@ -171,9 +171,8 @@ The session limits would be:
* write rate limit (writes over time) * write rate limit (writes over time)
* network request size * network request size
The system limits that can not be account over-riden are: The system limits that can not be account overridden are:
* maximum entry size * maximum entry size
* maximum number of multi value attributes * maximum number of multi value attributes