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

feat: add inline auth middleware #148

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

LucasRoesler
Copy link
Member

Description

This feature adds an authentication middleware to the of-watchdog. The authentication logic is loaded from external OPA policy files, so that function authors can customize the auth logic.

This policy can even be loaded via a Secret.

This middleware is configurable via several new environment variables, the user can customize: the policy, set a list of paths to skip authentication, control what request content is passed to the policy during evaluation (headers, raw body, json body, additional secret values, additional env variables).

In addition to loading and evaluating plain OPA rego policy files, the middleware defines two custom functions to enable more secure policy rules:

  1. bcrypt_eq exposes the bcrypt.CompareHashAndPassword method.
  2. constant_compare exposes the subtle.constant_compare method.

Extensive documentation of the configurations and behavior are now included in the README. Additional, example policies for Basic Auth, HMAC, JWT, and OIDC flows are included in the auth/testdata as well as unit tests that demonstrate how those policies behave.

Motivation and Context

  • I have raised an issue to propose this change (required)

If a function author is using a HTTP mode with a popular language and popular framework, they can probably implement this logic directly in the function. Adding it in the of-watchdog middleware means that:

  1. policies can be applied easily in all modes, for example forking and static modes will more easily support advanced auth flows like OAuth and OIDC.
  2. OPA Rego is language agnositc, so the same policy can be published and shared for any template or language. This reduces the complexity of ensuring that different functions are actually implementing the same policy rules because there is only one implementation.

OPA was chosen because it is part of the CloudNative landscape as a Graduated project and, for example, it is used by Istio.

How Has This Been Tested?

I have tested it locally with various test functions and via unit tests

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I've read the CONTRIBUTION guide
  • I have signed-off my commits with git commit -s
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Create a middleware that allows executing OPA policies prior to invoking
the function.

The policy can be configurd via the `OPA_POLICY` environment variable.
The query is defined via the `OPA_QUERY` variable. The OPA_POLICY can be
a comma separated list of paths.

The default query input will contain `path`, `method`, and the
`authorization` header value. You can optional include the parsed `body`
`rawBody` and the raw `headers` via the `OPA_INCLUDE_JSON_BODY`,
`OPA_INCLUDE_RAW_BODY` and `OPA_INCLUDE_HEADERS` environment variables.

Signed-off-by: Lucas Roesler <[email protected]>
Add `OPA_SKIP_PATHS` configuration and update the implementation to skip
these paths.

chore: add HMAC auth example in the tests

Signed-off-by: Lucas Roesler <[email protected]>
Signed-off-by: Lucas Roesler <[email protected]>
Support parsing structured auth policy results. This allows the policy
to customize the error response code. The policy can also attach
additional headers to the request so that the implementation. The
primary use case for the additional headers is to pass user or client
identification to the implmentation to allow for auditing and/or
additional authorization checks.

Signed-off-by: Lucas Roesler <[email protected]>
@LucasRoesler LucasRoesler changed the title Feat add inline auth middleware feat: add inline auth middleware Dec 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant