gitlabAug 6, 2026

GitLab Secrets Manager adds ESO, Terraform, API support (opens in new tab)

GitLab Secrets Manager expands beyond CI/CD by supporting Kubernetes, Terraform/OpenTofu, CLI tools, and external automation. Built on OpenBao and compatible with Vault APIs, it provides one centrally managed secret store with consistent access controls and auditing. The result is fewer duplicated credential stores and safer secret retrieval across the software delivery lifecycle. ## Kubernetes with External Secrets Operator - ESO uses its Vault provider to retrieve secrets from GitLab Secrets Manager. - A Kubernetes workload uses a short-lived GitLab-minted JWT to authenticate with OpenBao. - A `SecretStore` configures: - The Vault-compatible server and KV v2 mount - The GitLab organization, group, and project namespace - JWT authentication and the Kubernetes secret containing the token - An `ExternalSecret` maps remote secrets to a Kubernetes `Secret`. - ESO refreshes values according to `refreshInterval`, allowing rotated credentials to reach workloads without redeployment. - `remoteRef.key`, `property`, and `secretKey` define the source path, field, and destination key. ## Terraform and OpenTofu Integration - Terraform can retrieve secrets at plan or apply time instead of storing them in `.tfvars` files or CI/CD variables. - A script obtains a minted JWT and connection metadata through Terraform’s `external` data source. - The Vault provider uses that JWT to authenticate against GitLab Secrets Manager. - The `vault_kv_secret_v2` data source reads the required secret. - Outputs containing secrets should be marked `sensitive`, though downstream Terraform state handling still requires care. ## OpenBao and Vault CLI - Existing Vault-compatible scripts can access GitLab Secrets Manager without using the API directly. - Users configure `VAULT_ADDR` and `VAULT_NAMESPACE`. - A minted JWT is exchanged for an OpenBao client token through the configured JWT authentication path. - The `vault kv get` command then retrieves secrets from the KV mount. ## Secrets Manager API - The API supports automation outside GitLab CI/CD, Kubernetes, and Terraform. - A service account requests an access token through GitLab’s project API. - The response supplies the Vault server, namespace, mount, secrets path, JWT authentication path, and role. - External systems can use this information to authenticate and fetch secrets without hardcoded credentials or separate variable files. GitLab Secrets Manager is most useful when multiple deployment tools need the same credentials. Centralizing secrets in the OpenBao-backed store, using short-lived JWT authentication, and integrating through ESO, Terraform, CLI, or the API can reduce duplication and improve rotation and auditing.

secrets-managementk8sterraformjwt+4

lineJun 10, 2026

Transitioning from a Legacy Project to an AI-Driven Project: The AX Roadmap (opens in new tab)

AI transformation (AX) is not achieved by simply adding AI tools; it requires redesigning the team’s development system around AI. The post proposes a four-stage roadmap for turning legacy projects into AI-driven projects, beginning with security and standardization and progressing toward specification-based development automation. Its central recommendation is to introduce AI gradually, with clear documentation, human approval gates, and measurable outcomes. ## What an AI-Driven Project Means - AI participates throughout the development lifecycle, including: - Specification writing - Code generation - Testing - Code review - Pull request creation and merging - Developers focus more on direction, judgment, and business decisions rather than repetitive implementation work. - The key methodology is **spec-driven development (SDD)**: - Requirements and implementation specifications are defined before code. - AI generates, tests, and reviews code against those specifications. - Structured specifications compensate for AI’s difficulty in interpreting ambiguous intent. ## Stage 1: AI-Ready — Establish Security and Compliance The first stage creates a safe foundation for using AI with project context and company data. - Remove hardcoded secrets such as API keys, database passwords, and internal IP addresses. - Use secret-management services to inject credentials dynamically at runtime. - Protect personally identifiable information by masking or tokenizing names, emails, phone numbers, and similar data before sending it to AI systems. - Separate or restrict access to critical intellectual property, including proprietary algorithms and sensitive architecture. - Define minimum compliance requirements first rather than delaying adoption until every security improvement is complete. - Use sandboxing, system prompts, filesystem restrictions, and network isolation to limit AI access. - Validate that isolation mechanisms actually prevent sensitive-data exposure. Expected benefits include safer AI usage, faster debugging and repetitive coding, and accumulated team experience that supports later adoption stages. ## Stage 2: AI-Assist — Standardize Team Usage This stage addresses teams where individuals already use AI but follow inconsistent practices. - Create project-level AI guidelines covering: - Project context - Coding conventions - Architecture principles - Domain terminology - Establish shared prompts, skills, or plugins for activities such as: - Brainstorming - Writing implementation plans - Code review - Subagent-driven development - Integrate AI into CI/CD for automated first-pass code reviews. - Let AI identify style violations, likely bugs, and security issues. - Reserve human review for complex business logic, architecture, and policy decisions. - At this stage, AI assists with human-written code rather than independently implementing features. Possible KPIs include: - A reduction in repetitive human review comments. - Increased test coverage. - Improved deployment reliability and system stability. - More consistent adherence to team conventions. ## Stage 3: AI-Development — Automate Implementation The third stage connects specifications directly to working code through an automated pipeline. - The pipeline includes three human approval gates: 1. **Specification review:** Confirm requirements, scope, edge cases, and validation criteria. 2. **Implementation and test-plan review:** Approve the AI-generated execution and testing plans. 3. **Code review:** Approve the final implementation before merging. - AI uses documented domain knowledge and architecture context to generate project-specific code. - A new file in a directory such as `/specs` can trigger CI automation. - CI can generate an implementation plan, execute coding tasks through independent subagents, run tests, and create a pull request. - Approval steps ensure that AI cannot proceed to the next stage without human authorization. To improve adoption, the post recommends expanding AI’s responsibilities gradually: - Begin with unit- and integration-test generation for existing logic. - Move progressively toward boilerplate and broader implementation work. - Avoid delegating critical business logic immediately, since poor early results can undermine team trust. ## Overall Adoption Principles - Each roadmap stage provides value independently; teams do not need to complete all four stages at once. - The appropriate target depends on team maturity, risk tolerance, domain complexity, and adoption speed. - Documentation is essential because AI needs structured project and business context. - Human oversight remains important, especially for requirements, architecture, business rules, and final code approval. - Security controls, common workflows, and measurable KPIs should develop alongside AI usage. Teams should start with the safest achievable stage, standardize practices before automating implementation, and expand AI’s role only as documentation, testing, and review processes become reliable.

secrets-managementci-cdragsoftware-testing+3

gitlabMay 21, 2026

Manage CI/CD credentials with GitLab Secrets Manager (opens in new tab)

GitLab Secrets Manager, entering public beta with GitLab 19.0, provides a native way to manage CI/CD credentials without storing them in broadly scoped variables or configuration files. Built on OpenBao and integrated with GitLab’s existing permissions, environments, branches, and audit trails, it aims to reduce credential exposure and simplify incident response. The post recommends trying it in existing GitLab projects and pipelines, especially where least-privilege access is difficult to enforce. ## Where CI/CD Secrets Commonly Go Wrong - Developers often store credentials in: - Project- or group-level CI/CD variables - Configuration files - Accidentally committed `.env` files - Masked CI/CD variables may still be exposed to every job and anyone with pipeline access. - Standalone vaults improve separation but introduce: - A second authentication system - Separate permission models - Additional audit logs and operational overhead ## Using GitLab Secrets Manager - Secrets are stored within GitLab’s existing project and group structure. - Pipelines reference secrets with the `secrets:` keyword in `.gitlab-ci.yml`. - By default, GitLab writes the secret to a temporary file and exposes its path to the job. - Passing a file path instead of the raw value can reduce exposure in: - Subprocesses - Crash dumps - Telemetry systems ## GitLab-Based Access Controls - Secrets use GitLab’s existing users, groups, projects, and roles. - Permissions can be assigned for reading, creating, updating, and deleting secrets. - Group-level secrets are inherited by nested projects, allowing common credentials to be defined once. - Removing someone from a project or group immediately removes their access to its secrets. - This avoids maintaining a separate access hierarchy that could drift from GitLab’s permissions. ## Job-Level Secret Scoping - Each secret can be restricted based on: - Target environment - Branch - Whether the branch is protected - Wildcards such as `production/*` simplify environment and branch rules. - Multiple conditions can be combined, such as requiring both a protected branch and a production environment. - At runtime, the backend verifies the job’s identity and scope before returning the secret. - Secrets are discarded when the job ends, and job logs are masked. - Narrow scopes reduce the systems affected if a dependency or pipeline is compromised. ## Auditing Secret Usage - Secret creation, updates, and deletions appear in GitLab’s existing audit trail. - Pipeline secret reads include the originating pipeline and job IDs. - Responders can trace where a credential was used without correlating separate systems manually. - Audit logging is available for self-managed deployments; GitLab.com support is expected during the beta. ## Public Beta Availability - The beta is available to Premium and Ultimate users on GitLab.com and self-managed deployments. - GitLab Dedicated support is planned. - The feature is free during beta and will later become a paid GitLab Credits feature. - Existing integrations with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager remain available. GitLab Secrets Manager is best suited for teams that want least-privilege CI/CD credentials while keeping access control and auditing within GitLab. Teams can adopt it incrementally alongside existing external secrets platforms.

secrets-managementci-cdaccess-controlaudit-logging+3

cloudflareApr 14, 2026

Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP (opens in new tab)

Cloudflare argues that enterprise MCP adoption requires centralized governance rather than individually managed, locally hosted servers. Its reference architecture combines remote MCP servers, Cloudflare Access, MCP server portals, and AI security controls to improve visibility, authentication, policy enforcement, and performance. The company also introduces Code Mode with MCP server portals to reduce the token and context-window costs of exposing large APIs. ## Centralized Remote MCP Servers - MCP separates the AI application from corporate credentials and APIs: - The MCP client connects to the LLM or agent. - The MCP server mediates access to internal resources. - Cloudflare moved away from locally hosted MCP servers because they: - May use unvetted software and versions. - Increase supply-chain and tool-injection risks. - Are difficult for IT and security teams to administer. - A centralized team manages MCP infrastructure through a shared monorepo platform. - Approved teams can create governed MCP servers from templates, inheriting: - Default-deny write controls. - Audit logging. - Automated CI/CD pipelines. - Secrets management. - Servers are deployed remotely on Cloudflare’s developer platform and custom domains, providing centralized usage visibility and global low-latency access. ## Authentication with Cloudflare Access - Public MCP servers, such as documentation and Radar services, can remain openly accessible. - MCP servers connected to private corporate resources require employee authentication. - Cloudflare Access acts as the OAuth provider and identity layer. - It verifies: - Single sign-on. - Multifactor authentication. - IP address, location, and device-certificate context. - Access issues tokens that authorize users to reach protected resources. ## MCP Server Portals for Discovery and Governance - As the number of MCP servers grew, employees needed a central way to discover authorized services. - Users connect their MCP client to a portal, which exposes the internal and third-party MCP servers they are permitted to use. - Portals provide: - Centralized logging. - Consistent policy enforcement. - Data loss prevention controls. - Access policies for users and tools. - Administrators can restrict both portal access and the specific tools exposed by each server. - Finance users might receive only read-only repository tools. - Engineering users on corporate devices might receive read/write capabilities. - Portals support MCP servers hosted on Cloudflare as well as third-party servers. - Cloudflare emphasizes that the relevant security and networking components can run on the same physical machine in its global network, reducing latency and avoiding unnecessary traffic transit. ## Code Mode Reduces MCP Token Costs - The standard MCP design exposes every API operation as a separate tool. - For large platforms with thousands of endpoints, this exhaustive tool list consumes an agent’s context window and increases token costs. - Cloudflare presents Code Mode with MCP server portals as a way to address this scaling problem. - The provided article excerpt ends while introducing Cloudflare’s earlier use of server-side Code Mode for exposing large numbers of API endpoints. Cloudflare’s approach recommends treating MCP as enterprise infrastructure: centrally deployed, authenticated, discoverable, policy-controlled, and monitored. Organizations adopting MCP at scale should avoid unmanaged local servers and provide reusable platforms that make secure deployment the default.

secrets-managementcloudflareci-cdmodel-context-protocol+4