feat: support for Ory Network

[adamstrawson]

Adds support for Ory Network by adding a new api key flag.

When specified, the Authorization header is included in all requests.

Related Issue or Design Document

https://github.com/ory/hydra-maester/issues/132

Checklist

• [x] I have read the contributing guidelines and signed the CLA.
• [x] I have referenced an issue containing the design document if my change introduces a new feature.
• [x] I have read the security policy.
• [x] I confirm that this pull request does not address a security vulnerability. If this pull request addresses a security vulnerability, I confirm that I got approval (please contact [email protected]) from the maintainers to push the changes.
• [x] I have added tests that prove my fix is effective or that my feature works.
• [x] I have added the necessary documentation within the code base (if appropriate).

Further comments

[Demonsthere]

Hello there! Really happy to see the interest here :) Imho we cannot implementing the apiKey in such a way (plaintext value in the CR), rather use a secretReference and either mount or read the supplied secret, similar to secretName: my-secret-123

[adamstrawson]

Hello there! Really happy to see the interest here :) Imho we cannot implementing the apiKey in such a way (plaintext value in the CR), rather use a secretReference and either mount or read the supplied secret, similar to secretName: my-secret-123

I understand the concerns, we use Flux HelmReleases, so it's easy for us to inject these as secrets still. So two options come to mind if you have a preference?

1. Rather than using a flag, use an environment variable instead, and within the Helm Chart have a value to define the secret

{{- if .Values.apiKeySecret }}
    env:
    - name: HYDRA_API_KEY
      valueFrom:
        secretKeyRef:
          name: {{ .Values.apiKeySecret }}
{{- end }}

2. Similar to what you said, using a flag to set the secretName and then using the Kubernetes client to fetch the secret value.

[Demonsthere]

I think we can connect both approaches :) 1 - it is good for a global apiKey, which is then used by other resources. 2 - we can define CR level options like

apiKeySecretRef:
  name: foo

which is optional, and if not supplied we default to the secret in 1, if that is not defines too, don't use apikey altogether

[adamstrawson]

Disclaimer: I've only just recently starting picking up Go, so fairly new to it still - any feedback is appreciated!

This now supports both a global environment variable, or a CR level option.

Option 1: Environment Variable

If HYDRA_API_KEY is set, Authorization will be appended to all requests.

Open to suggestions on a more appropriate name for this variable too.

Option 2: CR Option

This will also replace any value defined in the global HYDRA_API_KEY environment variable.

spec:
  hydraAdmin:
    url: <ory_network_url>
    apiKeySecretRef:
      name: hydra-secret
      key: api-key # Optional
      namespace: auth # Optional

I'll leave the PR in draft for any feedback.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

adamstrawson seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}