DevOps-bootcamp · Lektion

Sentinel-policyer för styrning

Lär er att skriva och tillämpa policy-as-code med HashiCorp Sentinel för att säkerställa efterlevnad och styrning i alla era Terraform-driftsättningar.

Lektion 2 av 411 steg

Sentinel-policyer för styrning är en gratis lektion i DevOps-bootcamp på CoddyKit. Detta är lektion 2 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för DevOps-bootcamp, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i DevOps-bootcamp innehåller totalt 4 lektioner.

Introduktion till policy som kod och Sentinel

Tänk om ni automatiskt kunde säkerställa att era infrastrukturdistributioner följer vissa regler? Det är kraften i Policy-as-Code (PaC). PaC definierar regler för hur infrastruktur skapas och ändras på ett programmerbart sätt och för in styrning i ert utvecklingsflöde. HashiCorp Sentinel är ett kraftfullt PaC-ramverk som är utformat för detta ändamål.

Sentinels roll i Terraform

Sentinel integreras direkt med Terraform Cloud och Terraform Enterprise. Det fungerar som en grindvakt som utvärderar er Terraform-körplan innan några ändringar tillämpas i molnmiljön. Detta viktiga steg förhindrar att infrastruktur som inte uppfyller kraven eller är osäker någonsin provisioneras och upprätthåller regler proaktivt.

Policyer och verkställighetsnivåer

En Sentinel-policy är en uppsättning regler som skrivs på Sentinel-språket. När en policy aktiveras returnerar den true (godkänd) eller false (underkänd). Policyer kan konfigureras med olika verkställighetsnivåer:

  • Rådgivande: Varnar för överträdelser men låter åtgärden fortsätta.
  • Mjuk obligatorisk: Kräver ett uttryckligt åsidosättande för att icke-kompatibla ändringar ska få genomföras.
  • Hård obligatorisk: Blockerar helt åtgärder som inte uppfyller kraven och kräver att policyn följs.

Sentinel-policyns struktur

Sentinel-policyer definieras i .sentinel-filer. De innehåller vanligtvis importer, regler och ett huvudvillkor. Regeln main avgör om policyn godkänns eller underkänns.

En grundläggande policy kan se ut så här:

import "tfplan"

main = rule {
  tfplan.resource_changes is empty
}

Åtkomst till data från Terraform-körplanen

Importen tfplan tillhandahåller en strukturerad vy av Terraform-körplanen. Policyer använder dessa data för att granska:

  • tfplan.resource_changes: Detaljer om resurser som skapas, uppdateras eller tas bort.
  • tfplan.variables: Indatavariabler som tillhandahålls av konfigurationen.
  • tfplan.outputs: Utvärden från konfigurationen.

Dessa data är avgörande för att fatta välgrundade policybeslut baserat på vad Terraform avser att göra.

Exempel: neka ej godkända regioner

Vi skriver en Sentinel-policy som säkerställer att alla AWS-resurser endast distribueras i us-east-1. Policyn kontrollerar den region som har konfigurerats för varje AWS-resurs i planen.

import "tfplan/v2" as tfplan

allowed_regions = ["us-east-1"]

is_region_allowed = func(resource_change) {
  if resource_change.provider.name is "aws" {
    region = resource_change.provider.config.region else "us-east-1"
    return region in allowed_regions
  }
  return true # Not an AWS resource, allow
}

all_regions_compliant = all tfplan.resource_changes as _, rc {
  is_region_allowed(rc)
}

main = rule {
  all_regions_compliant
}

Policyfunktioner och operatorer

Sentinel tillhandahåller kraftfulla inbyggda funktioner och operatorer för komplex logik:

  • Samlingsfunktioner: all, any, filter, map för att iterera över listor och mappar.
  • Typfunktioner: is, type_of för att kontrollera datatyper.
  • Operatorer: Logiska (and, or, not) och jämförelseoperatorer (==, !=, >, <).

Med dessa kan ni skapa robusta och uttrycksfulla policyer som täcker olika scenarier.

Exempel: framtvinga obligatoriska taggar

Ett vanligt krav inom styrning är att framtvinga specifika taggar på resurser för kostnadsfördelning eller identifiering. Policyn säkerställer att alla nya eller uppdaterade aws_instance-resurser har taggen Project.

import "tfplan/v2" as tfplan

required_tags = ["Project"]

resource_has_required_tags = func(resource_change) {
  if resource_change.type is "aws_instance" {
    # Check if 'tags' attribute exists in the planned state
    if not ("tags" in resource_change.change.after) {
      return false
    }
    
    missing_tags = filter required_tags as tag {
      not (tag in resource_change.change.after.tags)
    }
    return missing_tags is empty
  }
  return true # Not an aws_instance, allow
}

all_instances_tagged = all tfplan.resource_changes as _, rc {
  (rc.change.actions contains "create" or rc.change.actions contains "update") ?
    resource_has_required_tags(rc) :
    true # Only check on create/update actions
}

main = rule {
  all_instances_tagged
}

Lokal testning av policyer

Innan ni distribuerar policyer till Terraform Cloud/Enterprise kan ni testa dem lokalt med Sentinel CLI. Med kommandot sentinel test kan ni definiera testfall med simulerade tfplan-data. På så sätt kan ni verifiera hur policyn fungerar och upptäcka fel tidigt, så att ni kan säkerställa att policyerna fungerar som avsett utan att påverka produktionsmiljöer.

Kontroll av policylogik

Ni behöver skapa en Sentinel-policy som förhindrar att AWS S3-buckets skapas med offentlig läsåtkomst. Vilken specifik del av tfplan-data skulle ni i första hand granska för att genomdriva detta?

Sammanfattning: styrning med Sentinel

Vi har utforskat HashiCorp Sentinel, ett kraftfullt ramverk för policy som kod och styrning:

  • Det integreras med Terraform Cloud/Enterprise för att upprätthålla regler.
  • Policyer utvärderar tfplan innan infrastrukturen tillämpas.
  • Olika verkställighetsnivåer (rådgivande, mjuk och hård) styr policyernas påverkan.
  • Ni kan skriva policyer som nekar regioner, framtvingar taggar och mycket mer.
  • Lokal testning säkerställer att policyerna fungerar som avsett före distribution.

Sentinel är avgörande för att upprätthålla efterlevnad, säkerhet och operativa standarder i alla era infrastrukturdistributioner.

Gratis att börja

Lär dig DevOps-bootcamp med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
142
Lektioner
568

Vanliga frågor

Är lektionen ”Sentinel-policyer för styrning” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen DevOps-bootcamp, inklusive ”Sentinel-policyer för styrning”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i DevOps-bootcamp innehåller totalt 4 lektioner.

Vad lär jag mig i ”Sentinel-policyer för styrning”?

Lär er att skriva och tillämpa policy-as-code med HashiCorp Sentinel för att säkerställa efterlevnad och styrning i alla era Terraform-driftsättningar. Ni övar på DevOps-bootcamp med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig DevOps-bootcamp?

Du behöver inga förkunskaper. Utbildningen i DevOps-bootcamp på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Sentinel-policyer för styrning”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här DevOps-bootcamp-lektionen?

Ja. Varje DevOps-bootcamp-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Mönster för flera moln och hybridmoln
  2. Sentinel-policyer för styrning
  3. Terraform Cloud och Enterprise
  4. Bygga anpassade providers
← Tillbaka till DevOps-bootcamp