feat(credentials): DISTR-370 add objectstore:// branch in resolve_credential_file for **Non-sensitive files**#1638
Merged
Conversation
Lalit3716-atlan
requested review from
Aryamanz29,
OnkarVO7,
atlan-ci,
cmgrote,
louisnow and
vaibhavatlan
as code owners
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
2 tasks
Contributor
📜 Docstring Coverage ReportRESULT: PASSED (minimum: 30.0%, actual: 79.5%) Detailed Coverage Report |
Contributor
📦 Trivy Vulnerability Scan Results
Report SummaryCould not generate summary table (data length mismatch: 9 vs 8). Scan Result Detailsrequirements.txtuv.lock |
Contributor
📦 Trivy Secret Scan Results
Report SummaryCould not generate summary table (data length mismatch: 9 vs 8). Scan Result Detailsrequirements.txtuv.lock |
Collaborator
☂️ Python Coverage
Overall Coverage
New FilesNo new covered files... Modified FilesNo covered modified files...
|
Collaborator
☂️ Python Coverage
Overall Coverage
New FilesNo new covered files... Modified Files
|
Contributor
|
🛠 Full Test Coverage Report: https://k.atlan.dev/coverage/application-sdk/pr/1638 |
1 similar comment
Contributor
|
🛠 Full Test Coverage Report: https://k.atlan.dev/coverage/application-sdk/pr/1638 |
Lalit3716-atlan
changed the title
Lalit3716-atlan
added a commit
that referenced
this pull request
May 5, 2026
… files (v2) Same docstring rewrite as #1638 — reframe the three input branches around what they're meant to carry, not just the format of the value: • Atlan upload (JSON ref) -> any file pushed through the UI • objectstore:// prefix -> NON-SECRET companion files bundled with the credential (krb5.conf, public CA certs, kerberos realm config). Customers with secret-manager size caps may also use it as a fallback for sensitive files with bucket-level IAM as the envelope. • raw base64 -> TRUE SECRETS resolved via the customer's secret manager + Dapr at activity time. No behaviour change — docstring + module comment + inline comment only.
Lalit3716-atlan
force-pushed
the
feat/DISTR-370-objectstore-credential-file
branch
from
f2b106f to
f4d1fed
Compare
Contributor
📦 Example workflows test results
|
Contributor
📦 Example workflows test results
|
Contributor
📦 Example workflows test results
|
cmgrote
previously approved these changes
May 5, 2026
Collaborator
|
@sdk-review |
Contributor
|
🔄 SDK Review starting (review) — ~10 min. Watch live progress |
Contributor
SDK Review: PR #1638 — feat(credentials): DISTR-370 add objectstore:// branch for non-secret companion filesVerdict: READY TO MERGE
Findings by File
Strengths
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
Lalit3716-atlan
force-pushed
the
feat/DISTR-370-objectstore-credential-file
branch
from
22c4e47 to
404a316
Compare
… companion files
A credential payload in Atlan can carry both true secrets (passwords,
keytabs, private keys) and non-secret companion files (krb5.conf, public
CA certificates, kerberos realm config) that the connector also needs at
runtime. Add a third dispatch path in resolve_credential_file so customers
can deliver those non-secret companion files through the same DEPLOYMENT
Dapr object store binding they already configured during SDR setup,
instead of forcing them through the secret manager.
Three input formats now dispatched:
• JSON {key,fileKey,...} -> Atlan upload object store (existing)
• objectstore://<key> -> customer's DEPLOYMENT binding (NEW)
• raw base64 string -> customer's secret manager (existing)
The objectstore:// path uses obstore streaming via download_file() with
DEPLOYMENT_OBJECT_STORE_NAME, so file size is bounded only by disk (no
in-memory materialization). Path validation rejects empty keys,
absolute paths, and ../ traversal segments.
Some customers also use this path as a fallback for truly sensitive
files (e.g. keytabs that exceed their secret manager's value-size cap),
relying on bucket-level IAM as the security envelope.
Backward compatible — existing JSON/base64 paths see no change.
…n files only Reviewer feedback: the previous wording softly condoned using objectstore:// as a fallback for sensitive files when the customer's secret manager has size limits. That undermines the design — true secrets belong in the secret store regardless of provider quirks, so they get audit, rotation, and break-glass. Replace the soft-fallback paragraph with an explicit 'NOT intended for true secrets' callout pointing readers at the base64 / secret-store branch for anything sensitive.
Lalit3716-atlan
force-pushed
the
feat/DISTR-370-objectstore-credential-file
branch
from
404a316 to
34bcad8
Compare
Lalit3716-atlan
added a commit
that referenced
this pull request
May 5, 2026
…n files only (v2) Same intent fix as the v3 PR (#1638) — strip the soft-fallback paragraph that condoned using objectstore:// for sensitive files when the customer's secret manager has size limits, and replace it with an explicit 'NOT intended for true secrets' callout. True secrets belong in the secret store regardless of provider quirks.
atlan-ci
approved these changes
May 5, 2026
Collaborator
atlan-ci
left a comment
atlan-ci
left a comment
There was a problem hiding this comment.
SDK Review: no blocking issues found. CI passing. Branch up to date. Approved.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A credential payload in Atlan can carry both true secrets (passwords, keytabs, private keys) and non-secret companion files (krb5.conf, public CA certificates, kerberos realm configuration) that the connector also needs at runtime. This PR adds a third dispatch path in
resolve_credential_fileso customers can deliver those non-secret companion files through the object store binding they already configured during SDR setup, instead of forcing them through the secret manager.{key,fileKey,...}objectstore://<key>The
objectstore://path uses obstore streaming viadownload_file(), so file size is bounded only by disk (no in-memory materialization). Path validation rejects empty keys, absolute paths, and..traversal segments.Why a third branch?
Some customers' secret managers have small per-value caps (e.g. 1 KB on certain on-prem AWS Secrets Manager configurations). A Kerberos
krb5.confis non-secret — it's just config — but it routinely exceeds those caps. Today such customers can't onboard SDR Hive at all because they have no path to deliver that file.The other realistic option — bouncing it through Atlan's hosted upload — defeats SDR's "your data stays in your environment" principle. Reusing the binding the customer already wired up for SDR object store gives us a same-environment delivery path with no new credentials and no new infrastructure.
Customers facing the same secret-manager cap on their actual sensitive files (e.g. larger keytabs) can also point this branch at those files, falling back on bucket-level IAM as the security envelope.
Backward compatibility
Strictly additive. Existing customers using the JSON or base64 branches see no change in behavior.
Related PRs (DISTR-370 stack)
credentialFileInputwidgetTest plan
TestResolveCredentialFile); all passobjectstore://→ file written (the Mastercard-shaped flow){key,...}→ file writtenValidation logs (excerpt)
🤖 Generated with Claude Code