Skip to content
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

Question. RBAC on jwt token #7913

Closed
weilip1803 opened this issue Aug 14, 2019 · 3 comments
Closed

Question. RBAC on jwt token #7913

weilip1803 opened this issue Aug 14, 2019 · 3 comments
Labels
question Questions that are neither investigations, bugs, nor enhancements stale stalebot believes this issue/PR has not been touched recently

Comments

@weilip1803
Copy link

weilip1803 commented Aug 14, 2019

It is known that istio employs RBAC through ServiceRole and ServiceRoleBindings. Can the RBAC filter do something similar to that? Will love an example

@mattklein123 mattklein123 added the question Questions that are neither investigations, bugs, nor enhancements label Aug 14, 2019
@cstrahan
Copy link
Contributor

Yes, this is something that we needed. Here's an example:

http_filters:
  - name: envoy.filters.http.jwt_authn
    config:
      providers:
        default_provider:
          payload_in_metadata: "payload"
          issuer: https://example.com
          local_jwks:
            # JWKS goes here (truncated for readability)
            inline_string: |
              { "keys": [ … ] }
      rules:
        - match:
            prefix: "/"
          requires:
            provider_name: "default_provider"

  - name: envoy.filters.http.rbac
    config:
      rules:
        action: ALLOW
        policies:
          "any":
            principals:
              - any: true
            permissions:
              - not_rule:
                  header: { name: ":path", regex_match: "/admin(/.*)?" }
          "admin":
            principals:
              - metadata:
                  filter: envoy.filters.http.jwt_authn
                  path:
                    - key: payload
                    - key: role
                  value:
                    string_match:
                      exact: admin
            permissions:
              - any: true

  - name: envoy.router
    config: {}

These are the docs you'll want to review:

This comment describes how payload_in_metadata works:

// If non empty, successfully verified JWT payloads will be written to StreamInfo DynamicMetadata
// in the format as: *namespace* is the jwt_authn filter name as **envoy.filters.http.jwt_authn**
// The value is the *protobuf::Struct*. The value of this field will be the key for its *fields*
// and the value is the *protobuf::Struct* converted from JWT JSON payload.
//
// For example, if payload_in_metadata is *my_payload*:
//
// .. code-block:: yaml
//
// envoy.filters.http.jwt_authn:
// my_payload:
// iss: https://example.com
// sub: test@example.com
// aud: https://example.com
// exp: 1501281058
//
string payload_in_metadata = 9;

FWIW, this is the PR that introduced the metadata for the jwt_authn filter: #4707

Lemme know if you have any trouble.

@stale
Copy link

stale bot commented Sep 15, 2019

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Sep 15, 2019
@stale
Copy link

stale bot commented Sep 22, 2019

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Questions that are neither investigations, bugs, nor enhancements stale stalebot believes this issue/PR has not been touched recently
Projects
None yet
Development

No branches or pull requests

3 participants