Skip to content

Feature Request: Airflow to support DAGs Git Sync using SSH Key #382

Closed
stackabletech/operator-rs
#1121

Description

@ruslanguns

The addition of SSH connection support for DAG Git Sync is proposed to enhance both the functionality and security of the API. This feature is already supported by the Official Helm Chart, which could serve as a valuable reference for implementation. Incorporating SSH connections would not only streamline the synchronization process but also bolster security measures during the sync operations

Thank you for considering this feature request.

Activity

  1. lfrancke commented on Feb 5, 2024

    @lfrancke
    Member

    Hi @ruslanguns
    Thank you for the issue.
    We talked internally and think it would be a useful feature.
    I have put it on the roadmap but it can be a while before we get to it. I'll update the ticket when we have an update.

    You might be able to get it working using config overrides as we believe all settings can be done using environment variables.

    We haven't tested this though!

  2. moved this to Selected for Development in Stackable End-to-End Coordinationon Nov 19, 2025
  3. moved this from Selected for Development to In Progress in Stackable End-to-End Coordinationon Nov 28, 2025
  4. moved this to Development: In Progress in Stackable Engineeringon Nov 28, 2025
  5. linked a pull request that will close this issuefeat: SSH access for gitsync #718on Dec 1, 2025
  6. linked a pull request that will close this issuefeat: CRD Versioning for airflow-operator #725on Dec 23, 2025
  7. added
    release-noteDenotes a PR that will be considered when it comes time to generate release notes.
    on Jan 15, 2026
  8. adwk67 commented on Jan 15, 2026

    @adwk67
    Member

    This issue has been implemented with CRD versioning for the airflow operator, meaning that this change is non-breaking.

    Release notes snippet

    Airflow can now use gitsync to authenticate against a repository using SSH keys as well as basic auth, which was previously the only option. The Airflow operator also now has the ability to convert certain changes between CRD versions: in the case of this change, the operator can automatically convert the field credentialsSecret to credentials:basicAuthSecretName so that this change is non-breaking. N.B. conversions in the opposite direction - from v1alpha2 to v1alpha1 - are not possible if the v1alpha2 resource definition refers to the new field.

    TODO

    Link the release note to the operator docs, and the operator docs (gitsync/ssh secton) to the release notes.

  9. reopened this on Jan 15, 2026
  10. added
    release-note/action-requiredDenotes a PR that introduces potentially breaking changes that require user action.
    on Jan 19, 2026
  11. moved this from Development: In Progress to Development: Done in Stackable Engineeringon Jan 20, 2026
  12. moved this from In Progress to Done in Stackable End-to-End Coordinationon Jan 21, 2026
  13. moved this from Development: Done to Acceptance: In Progress in Stackable Engineeringon Feb 4, 2026
  14. lfrancke commented on Feb 4, 2026

    @lfrancke
    Member

    You labeled it action-required @sbernauer. The release notes don't reflect that. Could one of you clarify?

  15. adwk67 commented on Feb 4, 2026

    @adwk67
    Member

    This should be linked to in the release notes: https://docs.stackable.tech/home/nightly/airflow/usage-guide/mounting-dags/#_via_git_sync
    This should be linked to in the operator docs: TODO (when release notes are finished)

  16. sbernauer commented on Feb 5, 2026

    @sbernauer
    Member

    You labeled it action-required

    Well, this is one of the very first cases of a breaking change that is mitigated using CRD versioning 😅
    So we need to figure out the process here, happy to discuss this!

    This change itself technically isn't breaking, but in a few months/years when we remove support for v1alpha1, that will be breaking. And for that the users need to know what the breaking change was and how to mitigate it.
    Maybe we should track the list of breaking changes using CRD versioning not in the platform release notes, but per CRD, as they are related to the CRD version, but not the platform version?

  17. lfrancke commented on Feb 10, 2026

    @lfrancke
    Member

    Understood, thank you. I think we can then mark it as breaking again when we remove old versions. For now at least.

  18. moved this from Acceptance: In Progress to Done in Stackable Engineeringon Feb 10, 2026
  19. sbernauer commented on Feb 10, 2026

    @sbernauer
    Member

    I agree with better safe than sorry and keep the action-required label

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions