-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(oidc): start mongodb with auth enabled to ensure we're testing it correctly #26
Conversation
done | ||
|
||
# Creates the OIDC user role in the database. | ||
mongosh "mongodb://localhost:27017/admin" --eval "JSON.stringify(db.createRole({ role: \"dev/groups\", privileges: [ ], roles: [ \"dbOwner\" ] }));" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The role(s) would need to match the entries inside the groups
claim, so that would be whatever OIDC_TOKEN_PAYLOAD_GROUPS
specifies (and we probably want to use that because it is supposed to be a parameter for this image, right?)
mongosh "mongodb://localhost:27017/admin" --eval "JSON.stringify(db.createRole({ role: \"dev/groups\", privileges: [ ], roles: [ \"dbOwner\" ] }));" | |
mongosh "mongodb://localhost:27017/admin" --eval "JSON.stringify((process.env.OIDC_TOKEN_PAYLOAD_GROUPS ?? 'testgroup').split(',').map(group => db.createRole({ role: 'dev/' + group, privileges: [ ], roles: [ \"dbOwner\" ] })));" |
or, if we’re sticking with a recent mongosh anyway,
mongosh "mongodb://localhost:27017/admin" --eval "JSON.stringify(db.createRole({ role: \"dev/groups\", privileges: [ ], roles: [ \"dbOwner\" ] }));" | |
mongosh "mongodb://localhost:27017/admin" --json --eval "(process.env.OIDC_TOKEN_PAYLOAD_GROUPS ?? 'testgroup').split(',').map(group => db.createRole({ role: 'dev/' + group, privileges: [ ], roles: [ \"dbOwner\" ] }));" |
(otherwise, the default is testgroup
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tbh maybe I overkilled it by making them configurable, wouldn't mind if we don't want to do that, just felt like it wouldn't hurt 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think it’s a bad idea at all, but yeah, if we really want to leverage this, we’d probably also want to give the user the ability to apply a specific role to each group (i.e. make this a map group → role rather than a list of groups) so that behavior actually differs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated - thanks for the help on this.
Previously we would keep default authentication enabled. This made it so that command would successfully run against the server when auth was failing, so testing with this config could give some false positives on behavior. This pr makes it so that the server requires auth for commands, and creates roles for the OIDC user to use.
It's currently in draft as I can't figure out what the correct
db.createRole
command should be for the mock oidc auth user.