bf2fc6cc711aee1a0c2a/kas-fleet-manager

End user should not be able to delete an internal service account https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/507#discussion_r684216780

Closed this issue · 1 comments

No, if they discover the service account internal id then they can delete it: but it is hard because the list is the entry point and currently there is a check for it #507 (comment)

Originally posted by @machi1990 in #507 (comment)

I would argue that secrecy of internal id is not sufficient. If we were to leak the user id (somehow - say log snippet shared during a support interaction), a malicious user could harm the system.

I would say that the end-user API should explicitly disallow the deleting of anything other than a end-user created service account.

No, if they discover the service account internal id then they can delete it: but it is hard because the list is the entry point and currently there is a check for it #507 (comment)

Originally posted by @machi1990 in #507 (comment)

I would argue that secrecy of internal id is not sufficient. If we were to leak the user id (somehow - say log snippet shared during a support interaction), a malicious user could harm the system.

I would say that the end-user API should explicitly disallow the deleting of anything other than a end-user created service account.

Hi @k-wall following your comment, I did add the check to prevent end user from deleting internal service account: https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/blob/main/pkg/services/keycloak.go#L366

The change was part of the PR: https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/507/files#diff-19390ff4b78f193e8d2f4e0fa6f0d0c05bd6fbcb05925b389d54ac02b533af4dR366. The check has been applied to other functionalities like: GetServiceAccountById and ResetServiceAccount.