You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The IETF provides some guidance on implementing OAuth 2.0. Whilst basic auth (used for the gateway administrative endpoints) is less sophisticated than OAuth 2.0, but there are some improvements we could make to the current model.
Brute-force mitigation
The implementation of basic-auth authentication for the Gateway can be enhanced to migrate brute-force / dictionary attacks by locking out the given user after too many incorrect login attempts.
Perhaps this could be done by reading Prometheus metrics - i.e. failed attempts over last 30 seconds and then create a configmap or allow the gateway to self-lock. This may even automatically expire.
Clear-text storage of passwords
Kubernetes (and possibly Swarm) appears to store credentials in plain-text, or makes them available in plain-text at runtime.
The authorization server may decide to enforce a complex user
password policy in order to increase the user passwords' entropy to
hinder online password attacks.
This seems like something we should absolutely do to protect the people that set admin/admin for their credentials and then expose the gateway endpoint on the public Internet. Since the credentials are created out of brand, the gateway could refuse to start if the credentials are weak in length/complexity.
Another option would be to use the basic-auth secret and store key-value pairs in there with user:password. An admin could add, remove and change users/passwords with kubectl.
The IETF provides some guidance on implementing OAuth 2.0. Whilst basic auth (used for the gateway administrative endpoints) is less sophisticated than OAuth 2.0, but there are some improvements we could make to the current model.
Brute-force mitigation
The implementation of basic-auth authentication for the Gateway can be enhanced to migrate brute-force / dictionary attacks by locking out the given user after too many incorrect login attempts.
https://tools.ietf.org/html/rfc6819#section-5.1.4.2.3
Perhaps this could be done by reading Prometheus metrics - i.e. failed attempts over last 30 seconds and then create a configmap or allow the gateway to self-lock. This may even automatically expire.
Clear-text storage of passwords
Kubernetes (and possibly Swarm) appears to store credentials in plain-text, or makes them available in plain-text at runtime.
It's recommended to hash these.
https://tools.ietf.org/html/rfc6819#section-5.1.4.1.3
Policy for passwords
This seems like something we should absolutely do to protect the people that set admin/admin for their credentials and then expose the gateway endpoint on the public Internet. Since the credentials are created out of brand, the gateway could refuse to start if the credentials are weak in length/complexity.
https://tools.ietf.org/html/rfc6819#section-5.1.4.2.1
Other areas
There are several other recommendations which we could implement with little effort.
Multi-user / auditing
If we enable multi-users for basic auth then we can also use that username in logging/auditing.
Start here
Help wanted in starting to suggest and implement improvements. The basic auth package is within the faas repo. https://github.com/openfaas/faas/blob/master/gateway/handlers/basic_auth.go https://github.com/openfaas/faas/blob/master/gateway/handlers/basic_auth_test.go
The text was updated successfully, but these errors were encountered: