Skip to content

Security and trust boundaries

The design combines concrete container, network and CI controls with demonstration simplifications. This page describes what each layer controls and which areas need another decision before using the pattern with real data.

Separate identities

Identity Responsibility Do not confuse with
GitLab user Changes, review and apply approvals Cloud account or pod identity
Pipeline cloud credential Create and manage resources Agent permissions for application deployment
CI_JOB_TOKEN Temporary job/state authentication as configured Permanent image-pull credential
TF_STATE_TOKEN Read previous layers' states Outputs that are inherently non-sensitive
CD credential Push to the manifest repository A Git Deploy Token with read-only scope
Agent token Connect an agent to GitLab User/CI RBAC authorization
Registry Secret Read images from pods Permission to modify Git repositories
MySQL user Access the application database Cloud administration identity

Conceptual separation supports reviewing each permission, but the repository does not contain every IAM policy or private GitLab role. Complete least privilege in the original accounts has not been established.

Declared controls

Containers run with explicit non-root UID/GID, disallow privilege escalation, drop capabilities, use seccomp and a read-only root filesystem. The rest and web ServiceAccounts disable automatic Kubernetes token mounting. The backend is exposed internally through ClusterIP. Databases use private networking, and AWS restricts RDS access to the EKS node security group.

Agents and platform provisioning have different permission requirements. Application pods lacking a mounted token does not imply equally restricted agent permissions. See agents and access.

Concrete boundaries

Application: requests are allowed without configured business authentication. TLS is disabled inside Spring servers; on AWS it terminates at the configured ALB. GKE TLS exposure needs additional configuration or clarification of the original procedure.

Network: private nodes coexist with public Kubernetes control-plane endpoints in default values. No application NetworkPolicies are versioned. Internal services and Secrets are distinct controls and do not replace traffic isolation or API access restrictions.

Data: RDS/Cloud SQL use demonstration parameters and deletion protection is disabled. AWS skips the final snapshot. Existing backups must be verified and restoration rehearsed; a backup declaration is not evidence of a successful restore.

CI: analyzers and summary jobs allow failures. Templates are consumed from main, several images/charts float and kubectl is downloaded without a pinned version. Keeping expanded configuration and pinning dependencies improves traceability.

States, plans and reports

States may contain passwords and Secret values; JSON plans may also reveal sensitive data. sensitive = true limits certain displays but does not remove values from state. Restrict access to projects, states and artifacts, and retain backups through an appropriate channel. Do not publish these files in this documentation site.

IaC artifacts are retained for one week in YAML, without a specific artifacts:access declaration. Check actual project visibility and GitLab-managed backend controls. This review did not inspect private variable values or download cloud state.

Prioritized evolution

  1. Complete the bootstrap contract: credentials, permissions, registry Secret and provider-specific exposure.
  2. Define real environment isolation, destruction policy and data recovery.
  3. Decide which analyses block deliveries and add tests/verified rollout.
  4. Pin versions and propagate the exact manifest revision between jobs.
  5. Review application identity, control-plane endpoints, RBAC and network segmentation.

These tasks form an evolution plan for the demonstrator. Each follows a concrete finding or requirement in the technical register, without inventing historical motivations.

Sources and traceability