Skip to content

helm chart: add Kubernetes Auth options #12314

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

Closed
wants to merge 2 commits into from
Closed

helm chart: add Kubernetes Auth options #12314

wants to merge 2 commits into from

Conversation

ufou
Copy link
Contributor

@ufou ufou commented Apr 25, 2022

What

Helm chart deployed pod-sweeper and worker pods both require k8s authentication to query the local cluster - this more often requires service account + tokens rather than mounting the kube config fixes #11323

  • Adds kubernetes authentication options:
    • use kube config inside pod
    • use service account/token inside pod

How

this PR offers the helm chart user flexibility to use either kube config or more probably service account + token

Add 2 new ENV vars:

  • KUBERNETES_AUTH_TRYKUBECONFIG
  • KUBERNETES_AUTH_TRYSERVICEACCOUNT
    If either is set to true then the pod will try to use the authentication method against kubernetes, afaik this is only worker and pod_sweeper

🚨 User Impact 🚨

Should be no breaking changes as the current behaviour is left as default

Pre-merge Checklist

Expand the relevant checklist and delete the others.

New Connector

Community member or Airbyter

  • Community member? Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Connector's bootstrap.md. See description and examples
    • docs/SUMMARY.md
    • docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
    • docs/integrations/README.md
    • airbyte-integrations/builds.md
  • PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • If new credentials are required for use in CI, add them to GSM. Instructions.
  • /test connector=connectors/<name> command is passing
  • New Connector version released on Dockerhub by running the /publish command described here
  • After the connector is published, connector added to connector index as described here
  • Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here
Updating a connector

Community member or Airbyter

  • Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Connector's bootstrap.md. See description and examples
    • Changelog updated in docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
  • PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • If new credentials are required for use in CI, add them to GSM. Instructions.
  • /test connector=connectors/<name> command is passing
  • New Connector version released on Dockerhub and connector version bumped by running the /publish command described here
Connector Generator
  • Issue acceptance criteria met
  • PR name follows PR naming conventions
  • If adding a new generator, add it to the list of scaffold modules being tested
  • The generator test modules (all connectors with -scaffold in their name) have been updated with the latest scaffold by running ./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates then checking in your changes
  • Documentation which references the generator is updated as needed

Tests

Unit

Put your unit tests output here.

Integration

Put your integration tests output here.

Acceptance

Put your acceptance tests output here.

@alafanechere
Copy link
Contributor

Hi @ufou, thank you for opening this PR. I'm going to review it soon, I also asked for @davinchia's eye 👀 😄

@@ -22,6 +22,9 @@ spec:
{{- end }}
spec:
serviceAccountName: {{ include "airbyte.serviceAccountName" . }}
{{- if and .Values.serviceAccount.create .Values.kubernetesAuth.tryServiceAccount }}
automountServiceAccountToken: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this set to true by default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to keep it consistent with the other pod that needs service account token access to k8s https://github.com/airbytehq/airbyte/blob/master/charts/airbyte/templates/worker/deployment.yaml#L22

## @param kubernetesAuth.tryServiceAccount if true, will try to use serviceAccount credentials from serviceAccount.name (default: false)
##
kubernetesAuth:
tryKubeConfig: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does tryKubeConfig do?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it tells you in the param section a couple of lines up:

## @param kubernetesAuth.tryKubeConfig if true, will try to use kube config mounted inside the pod (default: true)

I defaulted this to true as this is what seemed to be the way airbyte wanted to auth against k8s, given the errors in the logs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fabric link. I understand this now. What do you think about removing the try kube config option and switching on the service account? I don't think a user would want to want both to be set to true/false so this seems like a clearer configuration option to me. We can have this tryServiceAccount variable be the switch. What do you think?

Can we rename tryServiceAccount to useServiceAccount? That seems clearer to me.

Copy link
Contributor Author

@ufou ufou May 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fabric link. I understand this now. What do you think about removing the try kube config option and switching on the service account? I don't think a user would want to want both to be set to true/false so this seems like a clearer configuration option to me. We can have this tryServiceAccount variable be the switch. What do you think?

Yeah, sounds good - I'll make the changes - I could not think of a use-case for having kube config mounted inside a k8s pod - but did not want to deviate too much, but I agree - it doesn't make sense - I also think that useServiceAccount should default to true as, again, I can't see many scenarios where this is not the desired behaviour?

Can we rename tryServiceAccount to useServiceAccount? That seems clearer to me.

Yep, will do

@@ -239,6 +239,16 @@ spec:
configMapKeyRef:
name: {{ include "common.names.fullname" . }}-env
key: INTERNAL_API_HOST
- name: KUBERNETES_AUTH_TRYSERVICEACCOUNT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is using these env vars?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are most likely using a k8s client lib to interact with k8s, eg: https://github.com/fabric8io/kubernetes-client/blob/master/README.md#configuring-the-client

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Thanks for the link.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment here on adding the link to make it clear what is consuming this

@davinchia
Copy link
Contributor

@ufou I took a quick look. I don't understand how this fixes the stated issue. Can you explain more? Have you tested this on the infrastructure you want to support?

@ufou
Copy link
Contributor Author

ufou commented Apr 27, 2022

@ufou I took a quick look. I don't understand how this fixes the stated issue. Can you explain more? Have you tested this on the infrastructure you want to support?

Yeah, we've been running it like this for ~1 month - by default I think the client lib airbyte uses to interact with k8s, expects kube config to be available inside the pod, but for k8s on bare metal (and maybe cloud providers too?) this is not desirable, so instead the option to use service account token is available, the syntax I've used matches that of this client lib, which may or may not be the one airbyte uses: https://github.com/fabric8io/kubernetes-client/blob/master/README.md#configuring-the-client

@CLAassistant
Copy link

CLAassistant commented May 5, 2022

CLA assistant check
All committers have signed the CLA.

@@ -40,6 +43,16 @@ spec:
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: KUBERNETES_AUTH_TRYSERVICEACCOUNT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add the link to the fabric client documentation here to make it clear for users what is consuming these?

@davinchia
Copy link
Contributor

@ufou thanks for the explanation! I didn't realise you were running this on bare metal Kubernetes. I left some comments around simplifying the configuration. Lmk if this makes sense.

@ufou
Copy link
Contributor Author

ufou commented May 6, 2022

After merging upstream into my branch and testing again - these changes no longer seem to be required - I'm not sure if the underlying k8s auth mechanism has been updated or not but I no longer need to explicitly declare to use the service account token - and since the service account token is mounted by default this whole PR is moot - maybe the only thing of contention is whether the automountServiceAccountToken should be explicitly set to true in the pod sweeper deployment or not as it is in the worker deployment, but this works, so closing - sorry for the noise!

@ufou ufou closed this May 6, 2022
@ufou ufou deleted the helm-k8s-auths branch May 6, 2022 12:43
@alafanechere
Copy link
Contributor

@ufou I recently merge this helm chart PR, the auth was maybe required for creating PVC?

@davinchia
Copy link
Contributor

@ufou you are good! I'm not sure what changes would have solved this. Cannot think of any off the top of my head. Thank you for the contribution and sorry it took me a while to get back to you. Feel free to reopen if it's still causing you grief.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/platform issues related to the platform community kubernetes
Projects
None yet
5 participants