)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"342b3ee69b612791d1d8160ae5c9107f8eacf09f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0c855dff_752c762d","updated":"2026-04-29 08:53:38.000000000","message":"i am wondering whether keystone should check it at all, and not just rely on `keystone-manage doctor` for things like this.","commit_id":"9ac57015cc48eb556c725014409efd3d66c704c3"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"e3938d7a1853d9bfff95f18f93a25012c513d09d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4356458a_54c2edf1","updated":"2026-04-23 09:45:56.000000000","message":"what stops you from changing permissions for the secret in kubernetes?","commit_id":"9ac57015cc48eb556c725014409efd3d66c704c3"},{"author":{"_account_id":39086,"name":"Matthias Haag","display_name":"Matthias Haag","email":"matthias.haag@uhurutec.com","username":"mauhau"},"change_message_id":"08100868c060764d8d7820eb77e562cbfa4af27a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"48e66f8c_04631f09","in_reply_to":"0c855dff_752c762d","updated":"2026-05-01 08:42:58.000000000","message":"I would also be fine to remove the check for every auth request. With my proposal I wanted to stay as much backward compatible as possible 🙂","commit_id":"9ac57015cc48eb556c725014409efd3d66c704c3"},{"author":{"_account_id":39086,"name":"Matthias Haag","display_name":"Matthias Haag","email":"matthias.haag@uhurutec.com","username":"mauhau"},"change_message_id":"099f8a37993584dcf2f4ef0a354067384e68bdaf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"835ac923_b82c9ca4","in_reply_to":"4356458a_54c2edf1","updated":"2026-04-23 12:26:49.000000000","message":"Changing the permissions of the directory of the secret in Kubernetes was the first approach but unfortunately this is not possible: https://github.com/kubernetes/kubernetes/issues/129043\n\nIn real world it looks like this:\n\n```\nroot@keystone-api-864cb74689-fmpfx:/# ls -la /etc/keystone/fernet-keys\ntotal 0\ndrwxrwsrwt 3 root keystone 140 Apr 23 00:00 .\ndrwxr-xr-x 1 root root      88 Apr 22 16:21 ..\ndrwxr-sr-x 2 root keystone 100 Apr 23 00:00 ..2026_04_23_00_00_37.2401865055\nlrwxrwxrwx 1 root keystone  32 Apr 23 00:00 ..data -\u003e ..2026_04_23_00_00_37.2401865055\nlrwxrwxrwx 1 root keystone   8 Apr 22 16:19 0 -\u003e ..data/0\nlrwxrwxrwx 1 root keystone   9 Apr 22 16:19 30 -\u003e ..data/30\nlrwxrwxrwx 1 root keystone   9 Apr 23 00:00 31 -\u003e ..data/31\n\nroot@keystone-api-864cb74689-fmpfx:/# mount | grep fernet\ntmpfs on /etc/keystone/fernet-keys type tmpfs (ro,relatime,size\u003d16271720k,inode64,noswap)\n```\n\nUnfortunately it is not possible to influence the mount options with a umask or similar options.\n\nThe only possible way to avoid these warnings without this patch would be to copy the fernet keys during startup to the directory in the container, so without mounting the secret. But this would bring other drawbacks to the deployment.","commit_id":"9ac57015cc48eb556c725014409efd3d66c704c3"}]}