Cloud-IAM | DOCS

Appearance

Reducing the visibility of the deployment ​

Configuring the allow / deny list is a convenient way of reducing the visibility of your deployment over internet.

Allow lists ​

Allowlists
Allowlists

The allow / deny lists are split into two zones:

  • the first is the list for OpenID APIs (login, signup, tokens oAuth endpoints) which are the endpoints used by the end-users to get tokens
  • the second is the list for REST Admin API and Keycloak Admin Console urls. Those urls are meant to be used either by the Keycloak administrator, or by software that can provision / configure the realms for instance.

The list are composed of successive IPs or CIDRs that are evaluated in sequence (top to bottom). If the ip or the requester matches an entry, then the decision is applied and the evaluation stops.

If none matches, then the request is allowed.

INFO

Various IPs related to Cloud-IAM infrastructure, monitoring, ... are automatically granted and cannot be forbidden

Rate-limiting ​

For security and reliability reasons, the servers are protected with rate-limiting. The default value is 50 req/s for the OpenID APIs and 30 req/s for the Admin APIs.

Those values can be adjusted by the Cloud-IAM support team if needed.

INFO

IPs that have explicitly been granted (excepted 0.0.0.0/0) in the corresponding allow lists are excluded from rate limiting.

Request handling summary ​

1/ Allow list

Rules are tested in sequence. The first rule that matches is applied and the request is served or rejected. If no rule matches, the request is served.

List are different for the open-id and the admin sections.

2/ Rate limiting

Request rate limiting is applied to limit neighborhood noise and DDoS:

  • by default, 50 req / sec / ip on open-id urls
  • by default, 30 req / sec / ip on admin urls

All the addresses that have been explicitly marked as "allowed" in the lists are excluded from rate limiting for their specified zone. That means that the allowed IPs will never get rate limited for their zone.

WARNING

This can be useful to ensure the requests always reach the Keycloak server, but if an allowed IP starts making non-legit requests, or to flood the cluster, it might lead to disruption on the deployment.

List are different for the open-id and the admin sections

Note: even if you allow 0.0.0.0/32, this is obviously ignored for the rate-limiting exclusion.

3/ Bruteforce detection and DDoS

The Cloud-IAM processes try to detect abnormal behavior, enumeration attack, path brute force, DDoS, path traversal attack... If we detect such case, the requester IP will be banned for a few moments.

This detection process do not pay attention of which zone is concerned. The ban apply on the whole deployment.

However, all the IPs that have been explicitly allowed in one or the other allow list (0.0.0.0/32 excluded) will never be banned because of such behaviour.