A migration sidecar keeps database schema-change rights for the pod's whole life. How do you contain that elevation threat?
answer
- the work is momentary, the grant is not
- two jobs, two identities
- shrink the window, then the grant
- rare events make good alarms
- contained is not closed
basics
~10 sSeparate the principal and shorten the grant: run schema changes under a distinct identity in a short-lived step, narrow the rights, alarm on unexpected changes, and keep what remains as accepted residual risk.
solid answer
~50 sThe threat is that the privilege outlives the work: a compromise anywhere in the long-running application - a malicious transitive dependency is the realistic route - inherits schema control over the database for as long as the pod runs. I attack the mismatch between a momentary need and a permanent grant. First, separate the principal: migrations run under an identity the application process cannot use, in a step that exits when the migration finishes. Second, narrow the grant to the objects migrations actually touch, so schema control does not mean control of every schema. Third, add detection, since schema changes are rare and an unexpected one is a strong signal - that is compensating, not preventive. Finally, if the team keeps the sidecar for deployment reasons, that decision belongs in the model as an accepted residual risk with a named owner, not quietly dropped because a control was applied.
go deeper
Be able to say why a component should not hold powerful rights longer than it needs them, and that a compromise of the process inherits whatever rights it holds at that moment.
Explain the containment axes and what each buys: a separate identity, a shorter grant window, a narrower grant, and detection. Be clear that the last one finds the event rather than preventing it.
Show you can sequence these against real delivery constraints and say which you would take first. Expect to be pushed on whether review or alerting counts as a control, and to answer by naming the attacker position each one stops.
Own the acceptance: who decides, on what evidence, who carries the consequence, and what makes the model revisit it. Be ready to argue why a contained risk must stay visible rather than be closed as mitigated.
## State the threat properly before fixing it Write the sentence out: *code running in the application process, reached through a compromised transitive dependency, performs schema changes on the production database at any time during the pod's lifetime.* That is Elevation of Privilege - an actor performing operations it was never intended to perform - and stating it that way already tells you where the leverage is. The application's own function needs no schema rights at all. The migration needs them for seconds, once per deployment. The design grants them continuously to a process that runs for days. Notice what is *not* the threat. "The sidecar has DDL rights" is a condition of the design. "A dependency might be malicious" is an attacker position. The threat is the sentence that joins them and names the consequence, because that is the thing you can rate, mitigate and later close. ## The containment axes **Separate the principal.** The strongest move is that the identity holding schema rights is not an identity the application process can use. If the migration runs as its own principal, with its own credential, in a step that starts and finishes before the application serves traffic, then compromising the application yields the application's rights - which do not include changing schemas. This is the difference between least privilege as a slogan and least privilege as a boundary: two jobs, two identities. **Shorten the privilege's life.** Where separation is imperfect, shrink the window. Credentials that are issued for the migration and expire minutes later, or rights that are granted and revoked around the step, convert a permanent capability into a brief one. An attacker then needs to be present during a specific short window rather than any time in the next week, which is a genuine reduction in likelihood and a legitimate thing to record in the model. **Narrow the grant.** "Schema rights" is rarely one privilege. Migrations usually need to create and alter objects in one schema; they seldom need to drop other schemas, change ownership, alter the roles other services use, or read the data those tables hold. Splitting the grant means that even a successful elevation lands somewhere much smaller. Note that this bounds impact rather than preventing the event. **Detect what should be rare.** Schema changes happen on a known cadence, from a known step, at known times. Anything else is anomalous and worth an alert. Detection is compensating - it never stops the first unauthorized change - but when a preventive control is genuinely blocked, a compensating one plus a rehearsed response is a defensible position, and it is the only category of answer that keeps working when you have accepted the residual risk. ## When the privilege cannot be removed Sometimes the deployment model really does require the standing grant, and the honest principal answer is not to pretend otherwise. Three things make that acceptable rather than negligent. First, the residual risk stays **in the model** as an explicit, rated entry: which attacker positions reach it, what they gain, and why the preventive control was rejected. Second, it has a **named owner** - the person who owns the consequence, typically whoever owns the service's availability and data, not the engineer who noticed it. Third, it carries a **trigger for revisiting**: a change in the deployment mechanism, a growth in the number of services sharing the credential, or an incident elsewhere that changes the likelihood. What is *not* acceptable is closing the finding because a control was added. Least privilege, tighter grants and detection all **contain** an elevation threat; none of them removes it. A model that marks an entry mitigated when the privilege still exists has traded an accurate picture for a clean report, and the next person to read it will believe the wrong thing. ## Process is not a control A common counter-proposal is that migration scripts are reviewed before release, so the risk is handled. Review addresses mistakes by the team; it does nothing about an attacker who reaches the running process and never touches a migration script. When someone offers a process step in place of a runtime control, ask which attacker position it stops - if the answer is "a careless colleague", it is a quality control, not a security one, and the elevation threat is untouched. ## The tradeoff you are actually making Separating the principal costs something real: another credential to provision and rotate, another failure mode at deploy time, orchestration that must sequence the migration before the application starts, and a rollback story for a failed migration that no longer has a helpful sidecar sitting next to the app. Those costs land on the delivery team; the risk lands on whoever owns the data. Naming both sides, and taking the decision to the person who owns the consequence rather than deciding it inside the security review, is what makes this a principal-level answer rather than a checklist item.
- The team says migration scripts are peer-reviewed, so the risk is handled. How do you respond?I ask which attacker position review stops. Review catches a colleague's mistake in a script; it does nothing about code running in the process that never goes near a script, which is the threat we wrote down. Process steps are quality controls unless they change what the runtime can do. I would keep the review - it is useful - and say plainly that the elevation threat is unchanged by it, so it stays open until the privilege is separated, shortened or explicitly accepted.
- When is a detective control an acceptable answer to an elevation threat?When the preventive control is genuinely blocked, the event is rare enough that detection is reliable, and there is a rehearsed response fast enough to matter. Schema changes qualify on rarity: they happen on a known cadence from a known step, so anything else is a strong signal. What makes it acceptable is honesty in the model - the entry stays open as a contained risk with a compensating control, not closed as mitigated.
- How do you keep an accepted risk like this from quietly disappearing from the model?Give it three properties: a rated entry that states the attacker position and the gain, a named owner who owns the consequence rather than the code, and a trigger that forces a revisit - a change in the deployment mechanism, more services sharing the credential, or an incident that shifts likelihood. Acceptances without an owner and a trigger decay into folklore within a couple of team rotations, and the next reader assumes it was fixed.
saying these in an interview costs you the question
- Closes the finding once least privilege is applied
- Offers script review as the control for a runtime privilege
- Adds alerting only and calls the threat mitigated
- Assumes the privilege must be permanent because the deployment is convenient
- Accepts the risk with no owner and no revisit trigger
- Treats the standing grant itself as the threat statement