ory / hydra-maester Goto Github PK

Hi,

I can see in the API docs both redirect_uris and post_logout_redirect_uris are customizables (https://www.ory.sh/docs/hydra/sdk/api).

But in the maester CRDs nothing about the logout redirect URI property: https://github.com/ory/k8s/blob/master/helm/charts/hydra/charts/hydra-maester/files/crd-oauth2clients.yaml#L432-L438

I'm wondering if that's intended (merged or something like that)?

Thank you,

EDIT: I get whitelisting error for the login redirect URI, that's why I was looking for this

https://app.circleci.com/jobs/github/ory/hydra-maester/723?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification

Description

Create a controller that will allow registering hydra oatuh2 clients using Custom Resources.

• store ID of client, clientID and clientSecret in k8s secret in the same namespace of applied CR
• communicate with hydra over REST with retries
• use kubernetes endpoints to find out all hydra instances

Expected behaviour:

Oauth2 clients registered in Hydra have the same values as their corresponding CRs.

Actual behaviour:

The redirect_uris field is always empty.

Steps to reproduce:

1. Apply a custom resource with some RedirectURIs
2. Inspect the registered client through Hydra API (/clients endpoint)

Creating a client with this manifest works correctly

apiVersion: hydra.ory.sh/v1alpha1
kind: OAuth2Client
metadata:
  name: my-app-oauth-client
spec:
  grantTypes:
    - client_credentials
    - implicit
    - authorization_code
    - refresh_token
  responseTypes:
    - id_token
    - code
    - token
  scope: "read write"
  secretName: my-app-oauth-client

But using the following causes the secret name to not match the one in the spec (the metadata.name of the client was changed)

apiVersion: hydra.ory.sh/v1alpha1
kind: OAuth2Client
metadata:
  name: my-app
spec:
  grantTypes:
    - client_credentials
    - implicit
    - authorization_code
    - refresh_token
  responseTypes:
    - id_token
    - code
    - token
  scope: "read write"
  secretName: my-app-oauth-client

With the above, the created secret is my-app instead of my-app-oauth-client

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Network project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe the bug

I deploy Hydra v2.0.1 to k8s via Helm and I really love the idea to create OAuth2 clients via a CR.
However, with Hydra v2 it is no longer possible to change

ERROR	controllers.OAuth2Client	error processing client authentication-broker-oauth2-client/taal-evolution 	{"oauth2client": "register", "error": "POST http://authentication-broker-hydra-admin:4445/admin/clients http request returned unexpected status code: 400 Bad Request"}

on Hydra side:

level=info msg=An error occurred while handling a request audience=application error=map[debug: message:The request was malformed or contained invalid parameters reason:It is no longer possible to set an OAuth2 Client ID as a user. The system will generate a unique ID for you. status:Bad Request status_code:400] http_request=map[headers:map[accept:application/json accept-encoding:gzip content-length:407 content-type:application/json user-agent:Go-http-client/1.1] host:authentication-broker-hydra-admin:4445 method:POST path:/admin/clients query:<nil> remote:10.244.5.33:44274 scheme:http] http_response=map[status_code:400] service_name=Ory Hydra service_version=v2.0.1

Reproducing the bug

Deploy Hydra > v.2.0.0 and create a OAuth2Client CR for reconciliation by Hydra-Maester

Relevant log output

No response

Relevant configuration

No response

Version

v0.0.26

On which operating system are you observing this issue?

No response

In which environment are you deploying?

No response

Additional Context

No response

I have a kubernetes CRD like so

apiVersion: v1
data:
  client_id: Z3JhZmFuYS1vYXV0aDItZXhwZXJpbWVudA==
  client_secret: MTIzNDU2LWV4cGVyaW1lbnQ=
kind: Secret
metadata:
  name: grafana-oauth2-secret
  namespace: hydra
type: Opaque

---
apiVersion: hydra.ory.sh/v1alpha1
kind: OAuth2Client
metadata:
  name: grafana-oauth2-client
  namespace: hydra
spec:
  grantTypes:
    - client_credentials
    - implicit
    - authorization_code
    - refresh_token
  responseTypes:
    - id_token
    - code
    - token
  scope: "grafana"
  secretName: grafana-oauth2-secret

When I query a GET request to the admin server - http://hydra-admin:4445/client, I see two issues

1. The redirect_uris is null
2. The client_id, that was passed is set as client_name

{
    "client_id": "e2bd5fa5-9f6d-4773-9334-25310e522a23",
    "client_name": "grafana-oauth2-client",
    "redirect_uris": null,
    "grant_types": [
      "client_credentials",
      "implicit",
      "authorization_code",
      "refresh_token"
    ],
    "response_types": [
      "id_token",
      "code",
      "token"
    ],
    "scope": "grafana",
    "audience": null,
    "owner": "",
    "policy_uri": "",
    "allowed_cors_origins": null,
    "tos_uri": "",
    "client_uri": "",
    "logo_uri": "",
    "contacts": null,
    "client_secret_expires_at": 0,
    "subject_type": "public",
    "token_endpoint_auth_method": "client_secret_basic",
    "userinfo_signed_response_alg": "none",
    "created_at": "2019-10-16T23:12:34Z",
    "updated_at": "2019-10-16T23:12:34Z"
  }

This doesn't work because without setting the redirect_uris, hydra fails validation for oauth-client request

The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed" error=invalid_request hint="The \"redirect_uri\" parameter does not match any of the OAuth 2.0 Client's pre-registered redirect urls

But I could not find any way to set it.
I think the problem is that the current code is designed for grant type client_credentials even though it says that it is designed for all grant types. Because only that grant type doesn't need a redirect_uri

Hi,

We have a situation where we have all non prod environments in the same cluster but in different namespaces. We have set in every namespaces an hydra and hydra maester instance. The idea we have is when we add/update a client in hydra maester in namespace development then reconciliation should also happen only in hydra in development namespace.

But we found that OAuth2Client event seems to be pick in other namespaces not only in the ones where it was created and we don't know if it is possible to configure hydra controller manager to only process OAuth2Client with for some namespace.

In our client definition we configure the namespace:

apiVersion: hydra.ory.sh/v1alpha1
kind: OAuth2Client
metadata:
  name: oidc-client5
  namespace: demo

For now we have workaround the issue by using long domain name in client definition instead of the sort one.

hydraAdmin:
    url: https://hydra-admin.demo.svc.cluster.local
    port: 4445
    endpoint: /clients
    forwardedProto: https

With that we got an erro when the controller tries to reconcile a client from a different namespace.

ERROR   controller-runtime.controller   Reconciler error        {"controller": "oauth2client", "request": "sandbox-
authentication-management/oidc-client6", "error": "Get \"https://hydra-admin.sandbox-authentication-management.svc.cluster.local:4445/clients/oidc-
client6\": x509: certificate signed by unknown authority"}

We would like to know if it is posible to configure the controller in some what to only accept OAuth2Client from certain namespace.

Thanks in adavance.

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe your problem

Since Ory Network /admin endpoints require API Authentication, the use of hydra-maester isn't possible as there is no option to specific the Authorization header.

Describe your ideal solution

Ability to pass in the Ory Network API Key, so that hydra-maester is able to manage OAuth Clients correctly.

Workarounds or alternatives

N/A

Version

v0.0.29

Additional Context

PR Incoming.

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe the bug

If i do implicit grant with response_type=id_token+token and i configure OAuth2Client with:

  responseTypes:
    - id_token
    - token

I get The client is not allowed to request response_type 'id_token token'.
BUT If i manually create the client using POST & json body with

    "response_types": [
      "id_token token"
    ],

I am allowed to do implicit grant with response_type=id_token+token.
But maester wont let me configure response_types like that:

  responseTypes:
    - "id_token token"

Results in:

invalid: spec.responseTypes: Unsupported value: "id_token token": supported values: "id_token", "code", "token"

Reproducing the bug

1. Create kind: OAuth2Client with:

     responseTypes:
    - "id_token token"
   
   
   

Relevant log output

No response

Relevant configuration

No response

Version

oryd/hydra-maester:v0.0.24

On which operating system are you observing this issue?

No response

In which environment are you deploying?

Kubernetes with Helm

Additional Context

No response

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

I ran the installation guide to setup Ory Hydra v0.41.0 on a kubernetes cluster using the provided helm charts. The installation for both hydra-public and hydra-admin are successful along with a connection to a provided DSN. However, I am unable to solve the issues regarding the deployment of hydra-maester. The error is presented as:

invalid value "" for flag -hydra-port: parse error

I have followed the instructions from the documentation and set the following config variables:
hydra.config.dsn, hydra.config.urls.self.issuer, hydra.config.urls.login, and hydra.config.urls.consent.

Reproducing the bug

1. Follow installation through Ory Hydra helm chart documentation
2. Observe pods being deployed and find for the pod name
3. Run kubectl logs -n <namespace> <pod-name>
4. The error should be found within the first line of the logs

Relevant log output

invalid value "" for flag -hydra-port: parse error
Usage of /manager:
  -enable-leader-election
    	Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.
  -endpoint string
    	ORY Hydra's client endpoint (default "/clients")
  -forwarded-proto string
    	If set, this adds the value as the X-Forwarded-Proto header in requests to the ORY Hydra admin server
  -hydra-port int
    	Port ORY Hydra is listening on (default 4445)
  -hydra-url string
    	The address of ORY Hydra
  -insecure-skip-verify
    	If set, http client will be configured to skip insecure verification to connect with hydra admin
  -kubeconfig string
    	Paths to a kubeconfig. Only required if out-of-cluster.
  -leader-elector-namespace string
    	Leader elector namespace where controller should be set.
  -metrics-addr string
    	The address the metric endpoint binds to. (default ":8080")
  -namespace string
    	Namespace in which the controller should operate. Setting this will make the controller ignore other namespaces.
  -sync-period string
    	Determines the minimum frequency at which watched resources are reconciled (default "10h")
  -tls-trust-store string
    	trust store certificate path. If set ca will be set in http client to connect with hydra admin

Relevant configuration

No response

Version

0.0.33

On which operating system are you observing this issue?

Linux

In which environment are you deploying?

Kubernetes with Helm

Additional Context

No response

Hi folks,

Any reason why in recent release metadata type in hydra.ory.sh_oauth2clients.yaml has changed from object to byte string?

Expected:

   metadata:
      description: Metadata is abritrary data
      type: object

Actual:

   metadata:
      description: Metadata is abritrary data
      format: byte
      type: string

The only way I found to set object there is to base64encode the json string. But, in our case it breaks IDP, as we should do base64 decoding there.
And, it also seems that Hydra /clients endpoint didn't change in that perspective - metadata is still an object.

Previously, we were able to specify it in our yaml like this:

metadata:
    type: internal

And get response from hydra with appropriate object:

 {
   ...
   metadata: {
       'type': 'internal'
   }

And now if we want to specify object, we specify base64 encoded json string in yaml:

metadata: eyJ0eXBlIjoiaW50ZXJuYWwifQ==

And we get it as-is from hydra /clients endpoints:

 {
   ...
   metadata: "eyJ0eXBlIjoiaW50ZXJuYWwifQ=="
 }

Please, let me know if it was done purposely or is maybe some auto-generation issue?
I can do the PR, just let me know if I'm missing some puzzle here.

@colunira @aeneasr @Demonsthere

I have a use case:

• created a secret my-secret in namespace
• created a client in hydra using maester, referencing my-secret
• updated secret my-secret with a new client_secret value inside

I expect that maester will update client in hydra, but it obviouly doesn't right now.
Is there a way to do that?

The upstream issues got closed. It is referenced in:

• controllers/suite_test.go#L67

This issue was created by the ORY Closed Reference Notifier GitHub action.

Hey there,
is there a way of setting a fixed clientId for the OAuth2Client CRD. If not do you think it makes sense to add this because its quite dangerous that if a resource is accidentally removed that the new client gets a new Id.

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe the bug

Duplicate of ory/oathkeeper-maester#54

Reproducing the bug

Duplicate of ory/oathkeeper-maester#54

Relevant log output

No response

Relevant configuration

No response

Version

yes

On which operating system are you observing this issue?

No response

In which environment are you deploying?

No response

Additional Context

No response

As discussed in #26 there are a whole bunch of oauth client properties missing from the CRD spec.

See https://www.ory.sh/docs/hydra/sdk/api#schemaoauth2client for everything that can be set on an oauth client, at least in Hydra.

In order to make maester a production-ready solution for syncing oauth client registrations between Hydra instances, it should support all properties that an oauth client can have in Hydra

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Context and scope

With ory/hydra#3206, Ory introduced the config for token lifetimes by client, TokenType, etc.
The implementation in the latest Hydra releases do not make use of the fosite master branch implementation but has it's own variant, where the config params like AuthorizationCodeGrantAccessTokenLifespan is a direct attribute of Client instead of TokenLifespans like it is in fosite.

I want to add these new configs to hydra-maester.

Goals and non-goals

• hydra-maester is able to set the new lifetime configs in hydra

The design

I suggest to add TokenLifespans as a new optional attribute to the OAuth2ClientSpec, which then gets API version v1alpha2.
The controller is extended determine between these two versions,

1. Old Hydra + old Maester: Current state, no problem.
2. Old Hydra + new Maester: OAuth2ClientSpec at v1alpha2 are applies, Hydra ignores the new fields, sync successful for v1alpha1, unsuccessful for v1alpha2 definitions.
3. New Hydra + old Maester: The response of Hydra contains the new fields, which should be ignored by Maester, sync should be successful.
4. New Hydra + new Maester: Happy path.

APIs

No response

Data storage

No response

Code and pseudo-code

No response

Degree of constraint

No response

Alternatives considered

Alternatively, the new OAuth2ClientSpec could be amend by the new TTL configs as a flat attribute list. Like:

Metadata apiextensionsv1.JSON `json:"metadata,omitempty"`
// New:
AuthorizationCodeGrantAccessTokenLifespan x.NullDuration `json:"authorization_code_grant_refresh_token_lifespan,omitempty"
AuthorizationCodeGrantIDTokenLifespan x.NullDuration `json:"client_credentials_grant_access_token_lifespan,omitempty"
AuthorizationCodeGrantRefreshTokenLifespan x.NullDuration `json:"implicit_grant_access_token_lifespan,omitempty"

But that may be a bit ugly.

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe your problem

We want to implement the front-channel logout in one of our Oauth2 client application but the properties 'frontchannel_logout_uri' and 'frontchannel_logout_session_required' are not available in the CRD

Describe your ideal solution

Add 'frontchannel_logout_uri' and 'frontchannel_logout_session_required' to availabe properties in CRD file

Workarounds or alternatives

Use the CLI but things are not persisted

Version

hydra.ory.sh/v1alpha1

Additional Context

No response

I am constantly getting maester requesting secret at cluster scope error. Is this a feature or there's a bug in the RoleBinding in ory/k8s that needs to be fixed?

E0906 03:20:19.817318       1 reflector.go:126] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:94: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:identity-k8s-vidds-ee:hydra-maester-account" cannot list resource "secrets" in API group "" at the cluster scope
E0906 03:20:20.819535       1 reflector.go:126] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:94: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:identity-k8s-vidds-ee:hydra-maester-account" cannot list resource "secrets" in API group "" at the cluster scope
E0906 03:20:21.821676       1 reflector.go:126] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:94: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:identity-k8s-vidds-ee:hydra-maester-account" cannot list resource "secrets" in API group "" at the cluster scope
E0906 03:20:22.824112       1 reflector.go:126] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:94: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:identity-k8s-vidds-ee:hydra-maester-account" cannot list resource "secrets" in API group "" at the cluster scope
E0906 03:20:23.826419       1 reflector.go:126] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:94: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:identity-k8s-vidds-ee:hydra-maester-account" cannot list resource "secrets" in API group "" at the cluster scope
E0906 03:20:24.828602       1 reflector.go:126] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:94: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:identity-k8s-vidds-ee:hydra-maester-account" cannot list resource "secrets" in API group "" at the cluster scope
E0906 03:20:25.830754       1 reflector.go:126] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:94: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:identity-k8s-vidds-ee:hydra-maester-account" cannot list resource "secrets" in API group "" at the cluster scope
E0906 03:20:26.832843       1 reflector.go:126] pkg/mod/k8s.io/[email protected]+incompatible/tools/cache/reflector.go:94: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:identity-k8s-vidds-ee:hydra-maester-account" cannot list resource "secrets" in API group "" at the cluster scope

To accommodate the use-case of having multiple hyrda instances running in a cluster while still being able to the maester.

Currently you can only set up one --hydra-url when you start the app. Running multiple copies would lead to undesired behavior.

I am working on a patch that would add HydraURL, HydraPort, and HydraEndpoint to the CRD in order to allow the client to decide which hydra to use for registration. The original CLI flags would still be used and would be used as the default if the added CRD properties are missing. Otherwise it would override the values with what is present on the CRD (so in general, one would only need to set HydraURL assuming the deployments standardize the other values)

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe your problem

There's just no way to set jwks-uri, which is required for private_key_jwt.

Describe your ideal solution

Add jwks-uri to the client struct and pass it to hydra.

Workarounds or alternatives

No way around it if using this project.

Not using this project and using something else (i.e. curl script) is the only alternative.

Version

latest master

Additional Context

No response

Use what is already merged in #7 & #8 & #11

It's just uncommenting steps in circle ci config file. Goreleaser config is already merged

Starting with the introduction of ory/hydra#1707 new clients can no longer be added via a CRD since queries for unknown clients return a 401 response instead of a 404.

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe your problem

Please correct me if I'm wrong, but I could not find any mentions of the logo-uri, tos-uri and policy-uri in the CRD.

Describe your ideal solution

Have it implemented in the operator.

Workarounds or alternatives

Add it with the CLI, but that would be difficult to maintain in the long run.

Version

latest

Additional Context

No response

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Network project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe your problem

We have tooling that performs actions when a configmap/secret changes based on annotations.

It would be nice to be able to include metadata (specially annotations) within the secret that hydra-maester creates.

Describe your ideal solution

Within the Custom Resource, i'd like to define a spec template form which to create the secret, in a similar format to below:

apiVersion: hydra.ory.sh/v1alpha1
kind: OAuth2Client
metadata:
  name: my-client
spec:
  grantTypes:
    - client_credentials
  scope: my-scope
  secret:
    name: my-test-secret
    template:
      metadata:
        annotations:
          hello/world: foo
  clientName: foobar

The generated secret would then look like:

apiVersion: v1
kind: Secret
metadata:
  name: my-test-secret
  namespace: test
  annotations:
    hello/world: foo
  ownerReferences:
    - apiVersion: hydra.ory.sh/v1alpha1
      kind: OAuth2Client
      name: my-client
      uid: 1234-1234
data:
  client_id: aGVsbG8tZGlkLXlvdS1yZWFsbHktY2hlY2stdGhpcw==
  client_secret: aS13b3VsZC1saWtlLXNvbWUtcGllLXBsZWFzZQ==
type: Opaque

For backwards compatibility, we could support both secretName and secret.name with the intention of deprecating secretName in a future version.

Workarounds or alternatives

N/A

Version

N/A

Additional Context

Happy to PR if we feel this is a welcome addition.

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

This tripped me up for quite awhile, as I hit upon the error client_id property missing when creating my oauth client based on the sample configuration.

It turns out that the secret value keys client_id and client_secret have been changed to CLIENT_ID and CLIENT_SECRET by default now, which was difficult to figure out based on the emitted error and the documentation.

Reproducing the bug

To reproduce, simply kubectl apply one of the sample clients that deploys its own secret, either hydra_v1alpha1_oauth2client_user_credentials.yaml or hydra_v1alpha1_oauth2client_custom_namespace.yaml with a default configured instance of Hydra Maester 0.0.33 installed.

Relevant log output

No response

Relevant configuration

No response

Version

0.0.33

On which operating system are you observing this issue?

None

In which environment are you deploying?

Kubernetes with Helm

Additional Context

No response

Apparently, hydra maester once used the hydra.ory.sh/v1alpha2 api-version through 2 PRs #30 and #35.

And after discussion on #30, it was decided to stay on hydra.ory.sh/v1alpha1.

Sadly, one of the sample (https://github.com/ory/hydra-maester/blob/master/config/samples/hydra_v1alpha1_oauth2client_user_credentials.yaml#L11) wasn't properly updated.

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe the bug

After upgrade creating oauth2clients.hydra.ory.sh does not always create actual clients in Hydra which results in Unauthorized errors when trying to access the endpoint.
It might be caused the upgrade process itself. Reporting this here to track the solution.

Reproducing the bug

after creating instance of oauth2clients.hydra.ory.sh it creates and owns this secret:

pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » k get secrets lastorder-oauth 
NAME              TYPE     DATA   AGE
lastorder-oauth   Opaque   2      121m
pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » k get secrets lastorder-oauth -oyaml > lastorder-oauth-secret.yaml 
pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » cat lastorder-oauth-secret.yaml 
apiVersion: v1
data:
  client_id: ZDhjZTg5N2EtZWE0Yi00YzEzLWI3NTYtNTM3MmRiMWU4MWJi  # -> decodes to d8ce897a-ea4b-4c13-b756-5372db1e81bb
  client_secret: dUs3UF9FVVYtdWM2blF3T2NfNU1WOGRRQnA=
kind: Secret
metadata:
  creationTimestamp: "2022-03-01T20:16:24Z"
  name: lastorder-oauth
  namespace: test
  ownerReferences:
  - apiVersion: hydra.ory.sh/v1alpha1
    kind: OAuth2Client
    name: lastorder
    uid: 47d57eda-fe46-45f8-abdc-5d8f43dcba40
  resourceVersion: "8342"
  uid: 6256f534-4a0e-4daa-9a0a-fd04556ccbaa
type: Opaque

however when looking out for actual hydra clients the client is not present:

pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » k exec -it -n kyma-system ory-hydra-765b558996-xmm7x -- hydra clients list --endpoint http://127.0.0.1:4445/                                       1 ↵
|              CLIENT ID               | NAME | RESPONSE TYPES |            SCOPE            | REDIRECT URIS |    GRANT TYPES     | TOKEN ENDPOINT AUTH METHOD |
|--------------------------------------|------|----------------|-----------------------------|---------------|--------------------|----------------------------|
| ec8dac58-f47b-411d-8d7e-8413bc9efd5f |      |                | read write beb uaa.resource |               | client_credentials | client_secret_basic        |

After recreating the client secret is created with populated client data and the client is created in Hydra:

pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » k delete oauth2clients.hydra.ory.sh lastorder 
oauth2client.hydra.ory.sh "lastorder" deleted
pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » k get oauth2clients.hydra.ory.sh 
No resources found in test namespace.
pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » k apply -f lastorder-oauth2clients.hydra.ory.sh.yaml 
pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » k get secrets lastorder-oauth -oyaml 
apiVersion: v1
data:
  client_id: NTgwZTRjZGMtODg5YS00M2U5LTg2MzctNGNlZGIxOTM4ZTU0 # decodes to 580e4cdc-889a-43e9-8637-4cedb1938e54
  client_secret: YnYwNnJza2t3X3AxRHM4SV9YTUpHeWdkci4=
kind: Secret
metadata:
  creationTimestamp: "2022-03-01T22:21:23Z"
  name: lastorder-oauth
  namespace: test
  ownerReferences:
  - apiVersion: hydra.ory.sh/v1alpha1
    kind: OAuth2Client
    name: lastorder
    uid: 6eb333fa-39f3-4f11-b94f-cc9c294a299d
  resourceVersion: "67562"
  uid: 495115f3-51bf-45b0-95da-0f263ead88a8
type: Opaque
pkopec@piotr-nb tmp-ci-fast-integration-tests/bad-cluster » k exec -it -n kyma-system ory-hydra-765b558996-xmm7x  -- hydra clients list --endpoint http://127.0.0.1:4445/                                      1 ↵
|              CLIENT ID               | NAME | RESPONSE TYPES |            SCOPE            | REDIRECT URIS |    GRANT TYPES     | TOKEN ENDPOINT AUTH METHOD |
|--------------------------------------|------|----------------|-----------------------------|---------------|--------------------|----------------------------|
| 580e4cdc-889a-43e9-8637-4cedb1938e54 |      |                | read write                  |               | client_credentials | client_secret_basic        |
| ec8dac58-f47b-411d-8d7e-8413bc9efd5f |      |                | read write beb uaa.resource |               | client_credentials | client_secret_basic        |

Relevant log output

No response

Relevant configuration

No response

Version

v0.0.24

On which operating system are you observing this issue?

No response

In which environment are you deploying?

No response

Additional Context

No response

Hello,

I'm having in issue while using master to create a oauth client with tokenEndpointAuthMethod: none

E0325 11:54:20.980206       1 runtime.go:69] Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference)
/go/pkg/mod/k8s.io/[email protected]/pkg/util/runtime/runtime.go:76
/go/pkg/mod/k8s.io/[email protected]/pkg/util/runtime/runtime.go:65
/go/pkg/mod/k8s.io/[email protected]/pkg/util/runtime/runtime.go:51
/usr/local/go/src/runtime/panic.go:679
/usr/local/go/src/runtime/panic.go:199
/usr/local/go/src/runtime/signal_unix.go:394
/go/src/github.com/ory/hydra-maester/controllers/oauth2client_controller.go:233
/go/src/github.com/ory/hydra-maester/controllers/oauth2client_controller.go:123
/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:216
/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:192
/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:171
/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:152
/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:153
/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:88
/usr/local/go/src/runtime/asm_amd64.s:1357

I suspect the issue may be at :

What do you think ?

Describe the bug

We want to deploy multiple Hydra instances and use a single maester instance. The maester instance is in namespace A and the Hydra instances and OAuth2Client definitions are on namespace B.

All OAuth2Client definitions are specifying a hydraAdmin block to point to the corresponding Hydra instance admin. The maester however seems to ignore the override and uses the default admin URL.

To Reproduce

Steps to reproduce the behavior:

• Deploy a single instance of the hydra-maester Helm chart in namespace A
• Deploy one or more instances of Hydra using the hydra Helm chart (with maester.enabled set to false) in namespace B
• Deploy one or more OAuth2Client definitions specifying the hydraAdmin block in the spec to point to the deployed Hydra instance services.

Expected behavior

The maester should use the URL from the hydraAdmin block of the OAuth2Client definition and should register the client with Hydra admin instance successfully.

Environment

• Version 0.19.3 of both Helm charts
• GKE, v1.20.8-gke.900

Define CRD representing registration of oauth client.
CR should have field with name of k8s secret under in which client ID,ID & client Secret is stored.

Hi there,

I encountered a weird behavior that the metadata for a client is not saved to the database and also not in the deployed definition of the cluster.

Steps to reproduce:

1. Helm deployment of hydra-maester version 0.6.1
2. Applying the demo from here: https://github.com/ory/hydra-maester/blob/master/config/samples/hydra_v1alpha1_oauth2client_user_credentials.yaml

Outcome:
After doing this the client saved in the hydra database does not contain the expected metadata of {"property1": 1, "proerty2": "2"}.

The output of kubectl describe oauth2client my-oauth2-client-2 also does not show the metadata:

Name:         my-oauth2-client-2
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  hydra.ory.sh/v1alpha1
Kind:         OAuth2Client
Metadata:
  Creation Timestamp:  2021-04-15T15:16:59Z
  Finalizers:
    finalizer.ory.hydra.sh
  Generation:  2
  Managed Fields:
    API Version:  hydra.ory.sh/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:kubectl.kubernetes.io/last-applied-configuration:
      f:spec:
        .:
        f:audience:
        f:grantTypes:
        f:hydraAdmin:
          .:
          f:endpoint:
          f:port:
          f:url:
        f:metadata:
        f:redirectUris:
        f:responseTypes:
        f:scope:
        f:secretName:
        f:tokenEndpointAuthMethod:
    Manager:      kubectl-client-side-apply
    Operation:    Update
    Time:         2021-04-15T15:16:59Z
    API Version:  hydra.ory.sh/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:finalizers:
          .:
          v:"finalizer.ory.hydra.sh":
      f:status:
        .:
        f:reconciliationError:
    Manager:         manager
    Operation:       Update
    Time:            2021-04-15T15:16:59Z
  Resource Version:  3572774
  Self Link:         /apis/hydra.ory.sh/v1alpha1/namespaces/default/oauth2clients/my-oauth2-client-2
  UID:               f1e8e9c3-729d-4a90-a722-ee290b39d7b8
Spec:
  Audience:
    audience-a
    audience-b
  Grant Types:
    client_credentials
    implicit
    authorization_code
    refresh_token
  Hydra Admin:
    Endpoint:  /clients
    Port:      4445
    URL:       http://hydra.default.svc.cluster.local
  Metadata:   <------------------------------------------------------------------------ See here!
  Redirect Uris:
    https://client/account
    http://localhost:8080
  Response Types:
    id_token
    code
    token
  Scope:                       read write
  Secret Name:                 my-secret-456
  Token Endpoint Auth Method:  client_secret_basic

Best, Dennis

Extend Hydra helm charts with the controller plugged in as an additional container. Should be deployed if enabled in the values, by default disabled.

TODO:

• Read from secret the ID,ClientID,Secret
• Run cron job which iterates over all CR and tries to create them in hydra, 409 status code in response is treated as ok, continue
• use kubernetes endpoints to find out all hydra instances

It appears that it is not currently possible to run multiple deployments of hydra-maester at the same time in different namespaces. The problem appears to be that all hydra-maester instances look for all oauth2client instances regardless of namespaces. It seems like like this could be resolved by allowing an optional setting for namespaces under management and then all clients outside of those namespaces would be ignored.

Maybe I'm being ignorant and there is a way to handle this without code changes, but I can't seem to figure out how.

If I'm right and a code change is required I'm happy to do the work I just need to know if @aeneasr thinks it would be better to make the filter a Predicate added to the manager in the SetupWithManager method, as a check in the Reconcile method or some other mechanism I've yet to think of.

I am trying to work on #26 and I am having issues running the tests.

I managed to get it working with my minikube setup, but I am getting the following error:

assert: mock: I don't know what to return because the method call was unexpected.
	Either do Mock.On("GetOAuth2Client").Return(...) first, or remove the GetOAuth2Client() call.
	This method was unexpected:
		GetOAuth2Client(string)
		0: "testClientID"
	at: [HydraClientInterface.go:29 oauth2client_controller.go:95 suite_test.go:98 reconcile.go:93 controller.go:216 controller.go:192 controller.go:171 wait.go:152 wait.go:153 wait.go:88 asm_amd64.s:1357]

I tried to run mockery -name=HydraClientInterface in controllers/mocks but it returns the error Unable to find HydraClientInterface in any go files under this path

Hey there,
currently, it is required to set values for the scope spec in the OAuth2Client resource but as far as I understand for clients with the client_credentials grant type this is not really necessary (see https://www.ory.sh/hydra/docs/guides/oauth2-clients/#client-credentials-flow). Did I understand this correctly and is there a way to bypass this?

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe your problem

Current ory hydra container images support arm architectures. It would be nice if hydra-maester did to, this would allow full installation of ory hydra helm chart into arm devices for deployments on kubernetes clusters in the edge

Describe your ideal solution

Pipelines that build container images for all architectures

Workarounds or alternatives

Manual builds for arm container images

Version

0.0.23

Additional Context

No response

Secrets created by Hydra-maester should be deleted by Kubernetes upon deletion of parent OAuth2Client CR. If, however, the secret specified in the SecretName property exists, owner reference is not allowed.

Description:
Currently, as the default mode of operation for hydra is in-memory storage, in the case of hydra restart, all existing clients are purged from its memory. As those clients are seen as "already served", they won't be touched by the controller unless they are updated in some way. This can lead to a situation in which the CRs on the cluster do not represent what is stored in hydra.

Expectation:
Restarting hydra-maester should trigger some sort of mechanism that would regenerate the existing clients (from the CRs) and repopulate hydra.

I am trying to use TLS termination according to hydra server spec:
TLS termination

but there is not way to send X-Forwarded-Proto header in maester requests.

Is it possible to include property in helm values that allows such header to be sent?

thank you.

(Eg. hydra admin log)

level=info msg="started handling request" method=POST remote="172.17.0.6:41622" request=/clients
time="2019-11-06T08:51:53Z" level=warning msg="Could not serve http connection" error="X-Forwarded-Proto header is missing"
time="2019-11-06T08:51:53Z" level=error msg="An error occurred while handling a request" code=502 debug= details="map[]" error="can not serve request over insecure http"