github/deer-flow
1
0
Fork 0
mirror of https://github.com/bytedance/deer-flow.git synced 2026-07-27 16:37:55 +00:00
Code Issues Packages Projects Releases Wiki Activity
deer-flow/docker/lark-cli-init/README.md
Ryker_Feng 7aa314b4c1
feat: add Lark CLI integration (#3971) 
* feat: add lark cli integration

* fix: polish lark integration actions

* feat: support lark incremental permissions

* fix: detect lark authorization completion

* fix: harden lark integration install

* feat: expand lark auth scopes and reuse host auth in sandbox

Default lark auth to least-privilege (recommend=false, base sign-in only)
and expose the full set of lark-cli --domain business domains as native
--domain grants instead of a 4-domain read-only mapping. Resolve the
skill pack from the latest larksuite/cli GitHub release at install time
with content-hash integrity, and surface version/runtime drift in status.

Share the per-user lark-cli config/data profile between the Gateway
Settings auth flow and agent conversations by mounting the integration
dirs into the AIO sandbox and injecting the matching env for lark-cli
commands, with an allowlisted extra_mounts path in the provisioner/K8s
backend and traversal guards on integration paths.

* style: fix lint issues from ruff and prettier

Sort imports in the provisioner PVC test and re-wrap two long i18n
description strings to satisfy backend ruff and frontend prettier CI.

* fix(lark): address managed integration review feedback

* fix(frontend): stabilize integrations settings e2e

* test(sandbox): isolate remote backend legacy visibility check

* test: fix backend unit failures after merge

* Harden Lark integration review fixes

* Format Lark integration E2E test

* fix(lark): harden sandbox credential exposure and status disclosure

Address willem_bd's security review on PR #3971:

- Mount the per-user lark-cli config dir (long-lived appSecret) read-only
  into the AIO sandbox; only the refreshable-token data dir stays writable.
- Redact host filesystem paths (install_path, cli.path) from
  GET /lark/status and the config/auth complete responses for non-admin
  callers, fail-closed on any auth error.
- Document the npm postinstall trade-off (--ignore-scripts is not viable
  because @larksuite/cli fetches its platform binary in postinstall).
- Document the sandbox credential trust boundary in AGENTS.md and README,
  pointing at the sidecar-broker follow-up (#4338).

---------

Co-authored-by: Willem Jiang <willem.jiang@gmail.com>
2026-07-26 08:09:17 +08:00

2.7 KiB
Raw Permalink Blame History

lark-cli init image (Pattern A)

This image provisions the sandbox lark-cli runtime binary into a Kubernetes sandbox Pod via an init container + shared emptyDir, instead of the Gateway downloading Linux binaries from GitHub at install time and mounting them via hostPath/PVC.

See the design at docs/superpowers/specs/2026-07-21-lark-sandbox-init-container-design.md.

What it does

  • Build time (network available): downloads and SHA-256-verifies the official larksuite/cli Linux release binaries and stages the runtime layout under /opt/lark-cli:

    /opt/lark-cli/bin/lark-cli            # arch-dispatch launcher (uname -m)
/opt/lark-cli/linux-amd64/lark-cli
/opt/lark-cli/linux-arm64/lark-cli
/opt/lark-cli/.deerflow-lark-cli-runtime.json   # {"version": "vX.Y.Z"}

    This is byte-identical to what the Gateway writer (_write_lark_cli_sandbox_launcher) produces and what _validate_lark_cli_sandbox_runtime enforces, so the sandbox PATH contract (/mnt/integrations/lark-cli/runtime/bin/lark-cli) is unchanged.

  • Run time: copies /opt/lark-cli/. into the emptyDir mounted at ${LARK_CLI_RUNTIME_DEST} (default /mnt/integrations/lark-cli/runtime) and exits 0.

Build

docker build -t deer-flow/lark-cli-init:v1.0.65 \
  --build-arg LARK_CLI_VERSION=v1.0.65 \
  docker/lark-cli-init

The tag should encode the lark-cli version so it can be bumped independently of the upstream all-in-one-sandbox sandbox image.

Wiring it into the provisioner

The init-container runtime path is opt-in and off by default. Enable it by publishing this image and pointing the provisioner at it:

  • Set LARK_CLI_INIT_IMAGE on the provisioner service to the published tag (e.g. deer-flow/lark-cli-init:v1.0.65). Empty ⇒ legacy hostPath / Gateway download path (no behavior change).
  • When set, the provisioner adds a lark-cli-runtime emptyDir volume, an lark-cli-init init container, and a read-only runtime mount on the sandbox container — and ignores any /mnt/integrations/lark-cli/runtime hostPath/PVC extra mount (the init container supersedes it). The per-user config / data credential mounts are unchanged.
  • The provisioner reports whether it is configured via GET /api/capabilities ({"lark_cli_init_image": true|false}), which the Gateway surfaces as the Lark integration sandbox-runtime readiness signal in /api/integrations/lark/status.

Publishing note: this repository currently ships only backend/frontend images. Publishing a lark-cli-init tag is a fast-follow; until then the feature stays behind the empty-default LARK_CLI_INIT_IMAGE.