Listed in SECURITY.md under "Known limitations of a default deployment", which states each is tracked as an issue. This is that issue.
CONSOLE_PASSWORD (or its bcrypt form CONSOLE_PASSWORD_HASH) is one credential shared by everyone who opens the console. Auth.js issues a session from it; there is no user record and no identity in the session beyond "authenticated".
The consequence worth stating plainly: the console patches ConfigMaps, rolls Deployments, exec's into pods and rotates secrets, and auditLog() records that an action happened without being able to record who took it. For a showroom appliance that is a deliberate trade. For anyone running this where more than one operator has the password, the audit trail cannot answer the question it exists to answer.
Not a vulnerability report — this is the code as published. Filed so the limitation is visible and so the decision to change it (OIDC against the cluster's own IdP being the obvious route has somewhere to live.
EOF
)
Listed in SECURITY.md under "Known limitations of a default deployment", which states each is tracked as an issue. This is that issue.
CONSOLE_PASSWORD(or its bcrypt formCONSOLE_PASSWORD_HASH) is one credential shared by everyone who opens the console. Auth.js issues a session from it; there is no user record and no identity in the session beyond "authenticated".The consequence worth stating plainly: the console patches ConfigMaps, rolls Deployments, exec's into pods and rotates secrets, and
auditLog()records that an action happened without being able to record who took it. For a showroom appliance that is a deliberate trade. For anyone running this where more than one operator has the password, the audit trail cannot answer the question it exists to answer.Not a vulnerability report — this is the code as published. Filed so the limitation is visible and so the decision to change it (OIDC against the cluster's own IdP being the obvious route has somewhere to live.
EOF
)