What problem are you facing?
As a user of provider-opentofu, I need a secure and scalable way to authenticate and access private Terraform/OpenTofu configurations stored in remote GitHub repositories. Currently, using Personal Access Tokens (PATs) or SSH keys for programmatic access can have security and management drawbacks, such as:
-
Broad Permissions: PATs often require wider scopes than strictly necessary, increasing risk if compromised. ⚠️
-
Manual Rotation & Management: PATs and SSH keys require manual rotation and careful management, which can be cumbersome in automated CI/CD environments. 🔄
-
Tied to User Accounts: PATs are tied to individual user accounts, making auditing and revocation more complex when team members change. 🧑💻
This presents a challenge in adopting provider-opentofu in highly secure and automated environments where fine-grained access control and robust credential management are paramount.
How could Upbound help solve your problem?
Upbound could significantly enhance the security and operational efficiency of provider-opentofu by implementing support for GitHub App credentials for accessing private remote repositories. This feature is already successfully utilized by other prominent GitOps tools like FluxCD and ArgoCD, demonstrating its effectiveness and maturity:
Proposed Solution
We request the addition of a mechanism within provider-opentofu to configure and utilize GitHub App credentials (specifically, the App ID and Installation ID). The provider would then securely handle the retrieval and refreshment of the temporary access tokens generated by the GitHub App.
Benefits of this approach include:
-
Granular Permissions: GitHub Apps allow for highly specific permissions, limiting access only to what's absolutely necessary for the provider to function. 🎯
-
Enhanced Security: Credentials are not directly stored or exposed; instead, temporary tokens are used, and GitHub manages the underlying App authentication. ✨
-
Automated Management: GitHub Apps are designed for machine-to-machine authentication, making them ideal for automated pipelines and reducing the burden of manual credential rotation. ⚙️
-
Improved Auditability: Activity performed by a GitHub App is clearly logged as coming from the App, not an individual user. 🔍
Implementing this feature would provide provider-opentofu users with a robust, secure, and scalable method for managing their infrastructure code from private GitHub repositories.
What problem are you facing?
As a user of provider-opentofu, I need a secure and scalable way to authenticate and access private Terraform/OpenTofu configurations stored in remote GitHub repositories. Currently, using Personal Access Tokens (PATs) or SSH keys for programmatic access can have security and management drawbacks, such as:
Broad Permissions: PATs often require wider scopes than strictly necessary, increasing risk if compromised.⚠️
Manual Rotation & Management: PATs and SSH keys require manual rotation and careful management, which can be cumbersome in automated CI/CD environments. 🔄
Tied to User Accounts: PATs are tied to individual user accounts, making auditing and revocation more complex when team members change. 🧑💻
This presents a challenge in adopting provider-opentofu in highly secure and automated environments where fine-grained access control and robust credential management are paramount.
How could Upbound help solve your problem?
Upbound could significantly enhance the security and operational efficiency of provider-opentofu by implementing support for GitHub App credentials for accessing private remote repositories. This feature is already successfully utilized by other prominent GitOps tools like FluxCD and ArgoCD, demonstrating its effectiveness and maturity:
FluxCD Example: https://fluxcd.io/flux/cmd/flux_create_secret_githubapp/
ArgoCD Example: https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#github-app-credential
Proposed Solution
We request the addition of a mechanism within provider-opentofu to configure and utilize GitHub App credentials (specifically, the App ID and Installation ID). The provider would then securely handle the retrieval and refreshment of the temporary access tokens generated by the GitHub App.
Benefits of this approach include:
Granular Permissions: GitHub Apps allow for highly specific permissions, limiting access only to what's absolutely necessary for the provider to function. 🎯
Enhanced Security: Credentials are not directly stored or exposed; instead, temporary tokens are used, and GitHub manages the underlying App authentication. ✨
Automated Management: GitHub Apps are designed for machine-to-machine authentication, making them ideal for automated pipelines and reducing the burden of manual credential rotation. ⚙️
Improved Auditability: Activity performed by a GitHub App is clearly logged as coming from the App, not an individual user. 🔍
Implementing this feature would provide provider-opentofu users with a robust, secure, and scalable method for managing their infrastructure code from private GitHub repositories.