-
Notifications
You must be signed in to change notification settings - Fork 589
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
KeycloakService and friends #13355
KeycloakService and friends #13355
Conversation
|
||
from confluent_kafka import Producer | ||
|
||
class OAuthProducer: |
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.
do we plan to integrate oauth support into other kafka clients we use in ducktape (at least the ones that support it)?
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.
Good question. There's a line item on the epic to add oauth support to a Java client, but that's it afaik.
d7424b0
to
67c73ef
Compare
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.
Looks great.
It might be worth integrating this with https://github.com/redpanda-data/redpanda/blob/dev/tests/rptest/clients/python_librdkafka.py
67c73ef
to
4769ceb
Compare
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.
This is looking pretty good! Can you maybe reorder/squash up your commits? I can't speak for everyone else, but I like to review PRs one commit at a time, and if there are substantial changes in architecture between commits (i.e. you dropped oauth_producer in favor of using python_librdkafka, which is good!), it makes it a little bit confusing to do that.
tests/rptest/services/keycloak.py
Outdated
return len(self.pids(node)) > 0 | ||
|
||
def start_node(self, node, **kwargs): | ||
self.logger.warn("Starting Keycloak service") |
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.
nit: info level I think is the typical level we use for these sort of messages (if not debug)
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.
if not debug
So it is. Must have misread kerberos.py
@michael-redpanda - yeah, sorry. made those structural changes after Noah and maybe Ben had already taken a look. I'll squash 'em up now. |
ef0c5b1
to
03c4ab9
Compare
self.keycloak.clean_node(kc_node) | ||
assert False, "Keycloak failed to start" | ||
|
||
self.rpk.create_topic('foo') |
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.
You'll also need to create an ACL for the principal over this topic. The default mapping from the token to a principal is that the principal is extracted from the sub
claim of the access token (until that becomes more configurable).
In this case that might be service-account-{CLIENT_ID}
, depending on how Keycloak works.
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.
Looking great! Couple of nits
tests/rptest/services/keycloak.py
Outdated
# 'standardFlowEnabled': True, # authorization flow grant | ||
# 'directAccessGrantsEnabled': True, # resource owner password grant | ||
# 'implicitFlowEnabled': True, # implicit grant |
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.
nit: Any reason these should remain here? For code clarity can we remove commented out code.
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.
These are the flags to enable different grant types on the client; left them in for pseudo-documentation purposes because they're slightly obtuse. PRD calls exclusively for client-credentials
though; will remove.
f47a0fa
to
9141ded
Compare
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.
plz add a PR description
oops, not sure what happened there. done |
e931538
to
baaaa30
Compare
/cdt |
/cdt |
/cdt |
b9f7021
to
1182e7d
Compare
/cdt |
1182e7d
to
7a971a1
Compare
/cdt |
b22a158
to
a8552fe
Compare
/cdt |
force push to (actually) fix CDT finally |
# assert len(self.produce_messages) == 3, f"Expected 3 messages, got {len(self.produce_messages)}" | ||
# assert len(self.produce_errors) == 0, f"Expected 0 errors, got {len(self.produce_errors)}" |
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 idea is that these will be uncommented once paired with a working OIDC implementation in RP?
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.
Yep
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.
So my feeling with this is, uncommented them, mark the test @ok_to_fail
and then remove it once OIDC is integrated. Thoughts @BenPope ?
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.
Eh, maybe better to remove them? I still think the other assertions here have some value in terms of testing the test.
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.
Other option would be to just have this test be a simple service test (does this service actually work) and remove any comms with Redpanda and add them back later.
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.
Ripped a bunch of it out. Left a few things in to demonstrate service user manipulation and that librdkafka does the correct thing when passed the OAUTHBEARER algorithm, but the rest, I agree, was just noise.
a8552fe
to
08b2399
Compare
- Makes use of keycloak-python - Requires a lightly patched fork to get around a urllib3 version mismatch. - Methods for creating and updating users, clients
- Spins up a redpanda cluster and a KeycloakService - Creates a user under the demo realm, with realm-admin priv - Registers a client with keycloak - Update client's service account to include an email address - This will appear in the access token as the grant includes the 'email' scope. - Initializes PythonLibrdkafka with appropriate info (client ID, secret) - Sends some messages (this will fail without backend support)
08b2399
to
8660699
Compare
force pushed a rebase on dev - I think the branch fell a bit too far behind for CI |
/ci-repeat 1 |
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.
Looks great!
/cdt |
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.
lgtm
As work adding OIDC authentication to Redpanda gets underway, we would like to have
access to a locally installable/configurable identity provider service for the purposes of
experimentation and integration testing. This PR introduces a new ducktape service
(
KeycloakService
) to this end, built around the open source KeycloakIAM application.
Additionally, this PR integrates OAuth/OIDC support into the existing
PythonLibrdkafka
ducktape client and adds a
redpanda_oauth_test.py
. The latter contains a simple testto spin up a keycloak service and demonstrate that it is alive and servicing requests.
Fixes: https://github.com/redpanda-data/core-internal/issues/748 https://github.com/redpanda-data/core-internal/issues/755
Backports Required
Release Notes