GitLab Agent Dev Deploy

Status

Partial: repository config, namespace-scoped RBAC, install script, CI deploy path, and operator runbook are prepared. The live agent still requires GitLab registration and an operator-reviewed token install.

Related Requirements

• SRS references: secure deployment automation and operational readiness.
• Client response references: AWS is Phase 1 primary; operational simplicity and security guardrails matter.
• ADR references: AWS deployment architecture, AWS bootstrap/state strategy.
• Task board references: OP-044, OP-047.

Problem Statement

Direct Helm deploys from GitLab SaaS runners collided with restricted EKS public endpoint access and cluster access-entry complexity. The deploy path needs to stay GitOps-compatible without opening the EKS API broadly.

Architectural Intent

Run the GitLab Agent inside the dev EKS cluster and let GitLab CI deploy through the authorized Kubernetes context. Keep Terraform/OpenTofu responsible for infrastructure and Helm responsible for application release upgrades.

What Was Implemented

• Added .gitlab/agents/oneprotect-dev/config.yaml.
• Added namespace-scoped agent RBAC in deploy/kubernetes/gitlab-agent-dev-rbac.yaml.
• Added scripts/gitlab/install-dev-agent.sh for operator-reviewed agent installation.
• Updated deploy_aws_dev to require GITLAB_AGENT_KUBE_CONTEXT.
• Updated scripts/ci/helm-deploy.sh to use GitLab Agent mode without AWS CLI.

Components Involved

• GitLab Agent for Kubernetes
• GitLab CI deploy_aws_dev
• scripts/ci/helm-deploy.sh
• deploy/helm/oneprotect
• oneprotect-dev Kubernetes namespace

APIs / Events / Schemas

No product APIs or event contracts are added by this deployment-path change.

Deployment Notes

The GitLab Agent config must be present on the GitLab default branch before it is canonical. Register the oneprotect-dev agent in GitLab, create a token, then install it from an operator shell without committing or printing the token.

The expected CI context variable is:

GITLAB_AGENT_KUBE_CONTEXT=medhamsh/oneconnect:oneprotect-dev

Security / Tenant Isolation

• No GitLab Agent token is committed.
• The agent service account gets namespace-scoped admin only in oneprotect-dev.
• During dev bootstrap, the agent also has a temporary cluster-admin binding so the protected/manual pipeline can install AWS Load Balancer Controller. This is not a staging/production permission model.
• The Helm deploy job does not create cluster-scoped namespaces by default.
• Runtime Kubernetes Secrets remain outside Git and Helm values.

Validation Steps

UI Validation

After deploy succeeds, open the AWS dev frontend endpoint and confirm the operations console loads from the deployed frontend image.

API Validation

After deploy succeeds, call the AWS dev API health endpoint configured in AWS_DEV_API_HEALTH_URL.

Smoke Validation

Before live install:

bash -n scripts/ci/helm-deploy.sh scripts/gitlab/install-dev-agent.sh
make aws-dev-helm-render
make docs-check

After operator-reviewed agent install:

kubectl config get-contexts
kubectl get namespace oneprotect-dev
kubectl get serviceaccount gitlab-agent-oneprotect-dev -n gitlab-agent

Known Limitations

• GitLab Agent registration is still a live operator step.
• The default branch requirement means the config must reach main unless the GitLab project default branch changes.
• AWS Load Balancer Controller and smoke endpoint variables still gate a full external smoke result.

Follow-Up Work

• Register and install the dev GitLab Agent.
• Configure GITLAB_AGENT_KUBE_CONTEXT in GitLab.
• Run the protected deploy_aws_dev job.
• Capture first deploy results in this Feature Note.

Acceptance Criteria Mapping

Acceptance criterion	Evidence
Deploy path avoids direct SaaS runner EKS access	GitLab Agent context requirement
Token is not committed	Operator install script reads GITLAB_AGENT_TOKEN
Namespace access is bounded	deploy/kubernetes/gitlab-agent-dev-rbac.yaml
Existing GitLab CI flow is preserved	deploy_aws_dev remains manual and gated