Bicep Function
You use a bicep function to compute dynamic values inside your Azure templates during a deploy run. You call the built-in helper by name and pass your input values to get a clean output. Teams often use these helpers to build resource names, fetch keys, and join strings across files. Still, teams also grant wide admin roles to the deploy pipelines that run these templates. When a template helper fetches a storage key or database string, broad roles expose live data. How a bicep function works
Serverless Function Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use a bicep function to compute dynamic values inside your Azure templates during a deploy run. You call the built-in helper by name and pass your input values to get a clean output. Teams often use these helpers to build resource names, fetch keys, and join strings across files. Still, teams also grant wide admin roles to the deploy pipelines that run these templates. When a template helper fetches a storage key or database string, broad roles expose live data.
How a bicep function works in template deploys
A bicep function runs inside the template engine when you compile or deploy your cloud resources. You do not need to write custom logic from scratch for common string or math tasks. The language gives you built-in tools for string formatting, list joining, and scope lookups. You can also write user-defined helpers when your team repeats the same naming rule across files.
During a deploy run, the local tool compiles your template file into a standard JSON format. Some helpers resolve right away on your local machine before any network call happens. Other helpers wait until the cloud platform processes the template inside your target resource group. Scope helpers look up the current subscription, tenant, or resource group to build valid resource links.
Resource helpers can also read properties from existing cloud services that live outside your current file. Teams use these lookups to pull connection strings or shared keys into new app settings. This workflow keeps templates clean and avoids hardcoding account names or region codes in plain text. Every team member can reuse the same template across test, staging, and live cloud accounts.
Where native template helpers fall short on security
Native template helpers solve the problem of static, repeated values in your cloud setup files. They make sure resource names follow team rules and link services together without manual copy work. This setup works well for building out new cloud networks, storage accounts, and app hosts.
Still, template helpers also create a major blind spot when they handle secret values or keys. Many teams use built-in list helpers to read database keys and pass them to app settings. When the cloud engine runs that helper, the raw secret often lands in the deploy log. Anyone with read permissions on the resource group history can view those saved output values.
Cloud role assignments only check who can start a deploy run or read a template history. Those role checks do not inspect the individual commands or database queries that happen later. Once an engineer or service account pulls a database key from a deploy output, controls stop. The cloud role decides who logs in, not what individual statements or commands do in flight.
Serverless Function Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing secret lookups and live resource sessions
To reduce risk, teams should stop passing raw keys through template outputs and deploy histories. You can mark input parameters as secure so the engine leaves them out of basic logs. Even then, engineers still need direct ways to check databases and run fixes after a deploy. Giving every developer full read permissions on live resource groups exposes sensitive card numbers and emails.
Teams need a clear split between building cloud resources and running commands against live data stores. Template files should set up the empty server or database and assign basic network rules. Day-to-day queries and debugging tasks need command-level checks and data masking on returned fields. When masking rewrites emails or phone numbers in query results, engineers can fix bugs safely.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between built-in and user-defined helpers in Bicep?
Built-in helpers come with the language to handle strings, arrays, dates, and cloud scope lookups. User-defined helpers let your team write custom expressions once and share them across many template files.
Can a bicep function expose secrets in cloud deploy logs?
Yes, if a helper fetches an account key and passes it to a standard template output. The cloud platform saves standard outputs in the deploy history where other team members can read them.
When does the cloud engine evaluate template helpers?
The local tool evaluates simple math and string helpers when it builds the file. The cloud platform evaluates runtime helpers like resource lookups and scope checks during the live deploy.
Short role checks help teams work fast. Simple rules make each review clear. Good logs keep every team safe. Scoped keys stop bad changes early.