Terraform или OpenTofu: шифровани state мења избор, не брзина

За нови пројекат изаберите OpenTofu ако је услов да се state шифрује пре него што стигне у складиште и ако желите алат под отвореном лиценцом. Terraform је разуман избор када тим већ користи HCP Terraform за удаљено извршавање, управљање приступом и заједнички рад. За постојећи пројекат одлуку о преласку донесите тек пошто утврдите шта се дешава са state-ом и да ли нови алат предлаже неочекиване измене инфраструктуре.

Локална брзина команде није поуздана замена за ту процену. У стварном cloud окружењу време примене зависи и од позива API-ју провајдера, док шифровање одмах мења питања приступа, чувања кључа и повратка на стари алат. Зато најпре раздвојите избор CLI алата од избора платформе која извршава планове и чува state.

Одлука за нови пројекат

Ако ће сопствени CI покретати команде, а тим сам бира backend, проверите да ли осетљив state мора да буде шифрован пре уписа. У том случају OpenTofu доноси функцију у самом алату, али тим преузима и поступак за чување и опоравак кључева. Ако су одобравање промена, удаљено извршавање и приватни регистар већ организовани у HCP Terraform-у, њихова замена је део цене преласка.

• Самостални CLI и сопствени backend: упоредите шифровање у OpenTofu-у са заштитом коју backend већ пружа. Одредите ко може да добије кључ када CI или одговорна особа нису доступни.
• Постојећи HCP Terraform процес: попишите радне просторе, правила приступа, регистар и начин покретања планова. Промена бинарног фајла сама не преноси те услуге.
• Регулисано окружење: одредите ко сме да чита state, ко сме да покрене apply, где су резервне верзије и како се доказује опоравак. Одговор затим упоредите са контролама сваке понуђене поставке.

Ово раздвајање је важно и за мали тим који ради само локално. Њему интегрисана cloud платформа можда није потребна, али губитак једног кључа може зауставити рад над читавим state-ом. Већи тим може имати обрнут проблем: шифровање је решено, док би прелазак пореметио већ успостављено одобравање промена.

Шта заиста штити шифровани state

OpenTofu документација о шифровању описује заштиту state и plan фајлова при локалном чувању и раду са backend-ом. Када је функција укључена, копија шифрованог фајла није читљива без одговарајућег кључа. То је конкретна предност ако неко добије приступ складишту у ком се налазе осетљиве вредности.

Заштита има јасну границу: особа или процес који покреће tofu са исправним кључем може да прочита податке потребне за рад. Шифровање такође не поправља оштећен state и не спречава подметање старије верзије. Зато су права приступа, резервне копије и контрола верзија и даље део безбедносног решења.

Без исправног кључа шифровани state остаје недоступан и сопственом тиму. При избору система за управљање кључевима треба обезбедити приступ за CI, поступак опоравка и одвојене кључеве за различите state фајлове. OpenTofu дозвољава конфигурацију шифровања у коду или преко променљиве окружења; ако тим користи променљиву, може да захтева шифровање како изостављена вредност не би довела до уписа незаштићеног фајла.

Постојећи нешифровани state захтева изричиту прелазну конфигурацију која OpenTofu-у допушта да прочита стари облик и затим га поново запише шифрованог. За повратак на Terraform потребан је обрнут поступак док су првобитни кључ и метода још доступни. Зато миграцију алата и укључивање шифровања треба третирати као две одвојене промене.

Шта доноси HCP Terraform

HashiCorp-ов преглед издања наводи да HCP Terraform нуди удаљено извршавање, шифровано и верзионисано чување state-а, контроле приступа засноване на улогама и приватни регистар. То је шири скуп услуга од самог складишта. Тим може да повеже радни простор са системом за контролу верзија и тако покреће планове из свог уобичајеног процеса измена.

За одлуку о безбедности битно је где се подаци штите и ко управља окружењем за извршавање. OpenTofu омогућава шифровање у CLI току пре чувања state-а; HCP Terraform обједињује чување и контроле приступа у услузи. Само питање „да ли је state шифрован“ зато није довољно за избор у регулисаном окружењу: потребно је знати и ко има приступ читљивим подацима током извршавања.

Ако тим напусти HCP Terraform, мора да одреди где ће убудуће чувати верзије state-а, ко одобрава apply и како ће делити модуле. Сопствени backend и CI могу да покрију те потребе, али захтевају посебно подешавање и одржавање. За нови пројекат без таквог наслеђа овај трошак преласка не постоји.

Лиценца мења избор у одређеним пословним моделима

Поређење StackGuardian-а разликује OpenTofu под лиценцом MPL 2.0 и управљањем Linux Foundation од Terraform-а под HashiCorp лиценцом Business Source License. За организацију која алат користи да управља сопственом инфраструктуром то је другачије питање него за фирму која уграђује или хостује алат у комерцијалној услузи за трећа лица.

Тим у Србији који гради такву услугу треба да провери услове лиценце према тачном начину испоруке производа. За интерни инфраструктурни тим већи утицај могу имати правила набавке, постојећи уговор и доступност подршке. Отворена лиценца OpenTofu-а може бити захтев организације, али сама по себи не замењује контроле приступа нити решава управљање кључевима.

Зашто мерење брзине ретко пресуђује

У мерењу TechPlained-а на AWS конфигурацији са око 400 ресурса забележена времена за две алатке била су блиска: apply за измене на десет ресурса трајао је 45,2 секунде са Terraform-ом и 44,8 секунди са OpenTofu-ом. То је резултат наведене cloud конфигурације, не изоловано мерење рада CLI програма. Позиви AWS API-ју чине део укупног времена и могу да сакрију разлику у локалној обради.

Локални init, plan без измена или рад са ресурсима који не чекају cloud сервис могу показати другачији однос. Тај резултат има практичну тежину ако је управо тај корак чест и спор у вашем CI процесу. За примену стварне инфраструктуре корисније је раздвојити време преузимања provider-а, локалну обраду, приступ удаљеном state-у и чекање провајдера. Један укупан број не говори који део би промена алата убрзала.

Пробна миграција са могућношћу повратка

OpenTofu водич за миграцију почиње резервном копијом state-а и конфигурације, а затим предвиђа tofu init и tofu plan. Ако Terraform plan већ показује да је пројекат стабилан, очекивани резултат пробе је план без измена. Ако постоје унапред познате измене, оба плана треба да их приказују доследно; неочекивано стварање, замена или брисање ресурса разлог су да се apply одложи.

1. Сачувајте локални state или потврдите како се враћа верзија из удаљеног backend-а. Забележите верзије алата и provider-а и сачувајте конфигурацију у систему за контролу верзија.
2. Покрените Terraform plan као полазну тачку, потом tofu init и tofu plan над истом конфигурацијом. Упоредите предложене измене, подешавања backend-а и адресе извора модула и provider-а.
3. Када план нема неочекиваних измена, испробајте малу, некритичну промену. После успешне пробе прилагодите CI команде и поступак опоравка, па тек онда размотрите укључивање шифровања.

Посебно обратите пажњу на конфигурације које читају state других конфигурација преко terraform_remote_state: њихов редослед миграције зависи од приступа и начина шифровања сваког state-а. Ако проба не успе, зауставите OpenTofu операције, вратите state из копије ако је мењан и поново покрените Terraform plan. Тако повратак проверавате пре него што у продукцији уведете и нови формат заштите података.

Прочитајте и:

• Signal или Telegram: подразумевано шифровање мења цео избор
• Artlist или Epidemic Sound: лиценца за клијента мења јефтинији избор
• Рансомвер краде 896 TB — шифровање више није главни притисак