AWS Codepipeline Variables Feature Pipeline Variables
You use the aws codepipeline variables feature pipeline variables to pass values between stages. You set a namespace on an action and read the output later. Teams use this setup to share commit IDs, build numbers, and deploy targets. Still, pipelines often run with broad roles that grant too much power. When a stage runs a bad script, those broad roles put data at risk. How the aws codepipeline variables feature pipeline variables work A pipeline moves code from a source repo through build an
AWS IAM Policies + DevSecOps Pipeline Design: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the aws codepipeline variables feature pipeline variables to pass values between stages. You set a namespace on an action and read the output later. Teams use this setup to share commit IDs, build numbers, and deploy targets. Still, pipelines often run with broad roles that grant too much power. When a stage runs a bad script, those broad roles put data at risk.
How the aws codepipeline variables feature pipeline variables work
A pipeline moves code from a source repo through build and test stages. Each stage needs facts from earlier steps to do its job well. Before this feature existed, teams wrote custom files into cloud storage buckets. Each action had to pull that file and parse out the needed text. Now the control plane manages these key and value pairs for you.
First, you assign a unique namespace to a source, build, or deploy action. When that action finishes its run, it emits a set of output keys. The pipeline engine saves those keys under the namespace you chose earlier. Next, a downstream action asks for that key using standard variable syntax. The engine swaps the variable tag with the real value before the run starts.
You can also define pipeline level keys at the top of your workflow. These top level keys have default values that every stage can read. When you trigger a manual run, you can override those default values. This helps teams pick a target region or toggle a test flag fast. Every run keeps its own copy of the values from start to finish.
Passing values between build and deploy stages
Source actions emit basic facts like branch names and commit hashes right away. Build actions run your scripts and can export new custom keys too. You tell the build spec which shell values to save as output keys. Once the build job ends, those values flow back to the main pipeline.
Downstream deploy stages read those values to label releases or tag container images. You can pass the exact commit ID into a manual approval note. Reviewers read the note, check the commit, and approve the release step. This flow keeps every stage in sync without extra storage scripts.
Keep in mind that pipeline variables hold plain text in the console log. Anyone who can view the pipeline history can read these saved values. You must never pass raw passwords or private API keys through this channel. Instead, pass the name of a secret stored in a safe vault. The build job can then fetch the real secret when it runs.
AWS IAM Policies + DevSecOps Pipeline Design: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Where native pipeline roles leave a security gap
Native variables solve the problem of moving state across separate workflow stages. Cloud identity roles also decide which worker node can start a deploy task. Together, these tools handle basic workflow wiring and initial cloud login checks. Still, they only control what happens before a job starts its work.
Once a build or deploy container logs in, it holds full role permissions. The native pipeline cannot see inside the database queries or shell commands running. A broken script or a bad variable value can trigger a destructive command. If the worker role allows table drops, the database will run that query.
Also, build jobs that query live data may pull back raw user records. Native pipeline tools do not rewrite sensitive fields like emails or card numbers. If a script prints query results, private data lands in the build log. Teams need runtime checks that inspect every command and mask output fields.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can I store database passwords in pipeline variables?
No, you should never put passwords or private keys in pipeline variables. The console shows these values in plain text to anyone viewing the run history.
How do manual runs change default variable values?
When you start a pipeline run by hand, you can type new values. Those new inputs replace the default pipeline variables for that single run only.
When does the pipeline resolve action variables?
The pipeline resolves top level variables as soon as a new execution starts. It resolves action output variables right after the producing action completes its run.