Closed rauanmayemir closed 3 years ago
You're probably allocating too many resources for Argon2. Running Istio in Minikube is already a performance sink and adding Argon2 to the mix could make your VM unresponsive.
I did not realize Argon2 is that expensive. 😄 I'll try to adjust it.
Depends on the config but the defaults are pretty high: https://github.com/ory/kratos/blob/master/driver/configuration/provider_viper.go#L111-L115 (4GB RAM with 4 iterations with 2*CPU parallelism)
I've tried to adjust the config and it's still hanging:
hashers:
argon2:
memory: 524288
iterations: 2
parallelism: 1
salt_length: 16
key_length: 16
This is my minikube config:
{
"cpus": 4,
"dashboard": true,
"kubernetes-version": "1.18.3",
"memory": 8192,
"vm-driver": "virtualbox"
}
I'm just shocked this could be that resource-heavy.
Try iterations: 1
. Also make sure that the spike is really Kratos. Also keep in mind that you're running Istio in VirtualBox/Minikube and have not enabled the minimum requirements. Running applications that consume non-significant memory/cpu (such as password hashing) on Istio on a below-minimum resource machine is going to cause issues.
Start minikube with 16384 MB of memory and 4 CPUs. This example uses Kubernetes version 1.17.5. You can change the version to any Kubernetes version supported by Istio by altering the --kubernetes-version value:
By the way you're still using 512MB RAM, but on a machine that is already over-utilized by Istio. In our quickstart, we have dialed down everything quite a lot to make sure that it runs everywhere:
I wouldn't recommend doing that in prod though.
I changed the config to:
memory: 65536
iterations: 1
parallelism: 1
salt_length: 16
key_length: 16
But it's still crashing. Will try it later on the actual k8s cluster. I acknowledge that istio is super resource-hungry.
This works fine on a beefier hardware.
Ok, can I close this then or do you need further clarification? :)
Sorry for reviving an old thread, but it seems the most appropriate one.
https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10#section-4 ("Parameter Choice") says:
We suggest the following settings:
o Backend server authentication, that takes 0.5 seconds on a 2 GHz
CPU using 4 cores -- Argon2id with 8 lanes and 4 GiB of RAM.
o Key derivation for hard-drive encryption, that takes 3 seconds on
a 2 GHz CPU using 2 cores - Argon2id with 4 lanes and 6 GiB of
RAM.
o Frontend server authentication, that takes 0.5 seconds on a 2 GHz
CPU using 2 cores - Argon2id with 4 lanes and 1 GiB of RAM.
I would say that Kratos' is mostly used for Frontend server authentication but its default parameters are tuned for Backend server authentication. Would you accept a patch which tunes the parameters appropriately, or should I just tune them for my cluster and post my parameters on this thread?
All good, we should definitely document that and maybe also change the defaults used in the demo. If you're up for a PR @alsuren please go ahead :)
@tricky42 https://github.com/ory/kratos/issues/572#issuecomment-674804449 is relevant to you probably
I have a similar problem where the Kratos process becomes unresponsive. My Argon2 config is:
argon2:
parallelism: 1
memory: 65536
iterations: 1
salt_length: 16
key_length: 16
Still sometimes (not every time) when I try to perform login, Kratos process starts consuming 4+ cores of CPU and 4GB+ memory, then login request dies by timeout.
Example log:
time=2020-09-03T10:39:59Z level=info msg=completed handling request method=POST name=public#https://my-domain/.ory/kratos/public remote=172.30.134.6 request=/self-service/browser/flows/login/strategies/password?request=f1959ca9-8288-4936-a4dd-bd18ebaca97c request_id=5145e17fbf79383a92b437d852ccf889 status=302 text_status=Found took=52.018030695s
I'm running Kratos in Kubernetes, and while that request lasts, the pod becomes unready.
Make sure to have allocated enough CPU and memory limits!
Thanks, I'll try it.
I was concerned by kubectl top pod
output that showed 4+ cpu core usage. But that may be due to overall node cpu saturation probably.
Describe the bug
I've been trying to set up kratos
v0.4.4
with selfservice-ui-node locally in minikube. While slow, I managed to succeed with registering and verifying my identity.However, trying to login simply hangs the service. Occasionally it makes the whole minikube unresponsive, so I have to completely shut it down and restart.
I caught the liveness status updates that gives a clue of what happened:
It seems like kratos pod choked on the login request and even stopped responding to health requests, so k8s just restarted the pod.
Here's what was in the kratos logs from the time when I opened the selfservice at https://auth.ips.test (this time k8s weren't able to restart the pod and simply hang):
Reproducing the bug
Here's my config:
image: repository: oryd/kratos tag: v0.4.3-alpha.1-sqlite pullPolicy: IfNotPresent
service: admin: enabled: true type: ClusterIP port: 80 annotations: {} public: enabled: true type: ClusterIP port: 80 annotations: {}
kratos: development: true autoMigrate: true
config: dsn: "postgres://connection" secrets: cookie:
omitted
identity: default_schema_url: file:///etc/config/identity.traits.schema.json
courier: smtp: connection_uri: smtp://uri/ from_address: notifications@example.com serve: public: base_url: https://auth.ips.test/.ory/kratos/public admin: base_url: http://ips-auth-kratos-admin.default.svc.cluster.local/
selfservice: default_browser_return_url: https://auth.ips.test/ strategies: password: enabled: true
flows: error: ui_url: https://auth.ips.test/error
I manually updated helm-generated configmap to include
/etc/config/identity.traits.schema.json
, got the default one from the latest tagged kratos release.Environment