Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Layered Governance for your Infrastructure with Kubernetes, OPA, and Terraform

Layered Governance for your Infrastructure with Kubernetes, OPA, and Terraform

When writing policy as code, we aim to implement the best practices in our work, but we might not always know how to iterate on policies, nor how to make them transparent to the teams we work with.

The best way to enforce policy is to make it easy and to incorporate these practices into an automated pipeline that will make for efficient workflows and by making all policies visible to end-users. We will demonstrate using the Open Policy Agent, Terraform, and Flux in a declarative fashion.

Taylor Dolezal

February 06, 2021
Tweet

More Decks by Taylor Dolezal

Other Decks in Technology

Transcript

  1. Agenda GitOps Cloud Native Continuous Deployment Policy as Code Enforcing

    Policy Automatically Live Demo Terraform, Flux, OPA, and Kubernetes
  2. GitOps ▪ Framework using DevOps best practices ▪ Enables Collaboration

    ▪ Helps Govern Access Control ▪ Less Risk, Less Error Prone
  3. GitOps ▪ Framework using DevOps best practices ▪ Enables Collaboration

    ▪ Helps Govern Access Control ▪ Less Risk, Less Error Prone ▪ Acts as a Feedback Loop
  4. Bootstrap ▪ The process of installing the Flux components ▪

    Manifests are applied to a cluster, a GitRepository and Kustomization are created for the Flux components, and the manifests are pushed to an existing Git repository (or a new one is created)
  5. Bootstrap ▪ The process of installing the Flux components ▪

    Manifests are applied to a cluster, a GitRepository and Kustomization are created for the Flux components, and the manifests are pushed to an existing Git repository (or a new one is created) ▪ Flux can manage itself just as it manages other resources
  6. Sources ▪ Defines the origin of a source and the

    requirements to obtain it ▪ GitRepository
  7. Sources ▪ Defines the origin of a source and the

    requirements to obtain it ▪ GitRepository ▪ HelmRepository
  8. Sources ▪ Defines the origin of a source and the

    requirements to obtain it ▪ GitRepository ▪ HelmRepository ▪ Bucket
  9. Kustomization ▪ Represents a local set of Kubernetes resources that

    Flux is supposed to reconcile within a Kubernetes cluster
  10. Reconciliation ▪ Ensuring that a given state matches a declarative

    desired state ▪ HelmRelease reconciliation
  11. Reconciliation ▪ Ensuring that a given state matches a declarative

    desired state ▪ HelmRelease reconciliation ▪ Bucket reconciliation
  12. Reconciliation ▪ Ensuring that a given state matches a declarative

    desired state ▪ HelmRelease reconciliation ▪ Bucket reconciliation ▪ Kustomization reconciliation
  13. Add podinfo repository to Flux TERMINAL $ flux create source

    git podinfo \ --url=https://github.com/stefanprodan/podinfo \ --branch=master \ --interval=30s \ --export > ./staging-cluster/podinfo-source.yaml
  14. GitRepository Manifest CODE EDITOR apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository metadata: name:

    podinfo namespace: flux-system spec: interval: 30s ref: branch: master url: https://github.com/stefanprodan/podinfo
  15. Deploy podinfo application TERMINAL $ flux create kustomization podinfo \

    --source=podinfo \ --path="./kustomize" \ --prune=true \ --validation=client \ --interval=5m \ --export > ./staging-cluster/podinfo- kustomization.yaml
  16. Kustomization Manifest CODE EDITOR apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name:

    podinfo namespace: flux-system spec: interval: 5m0s path: ./kustomize prune: true sourceRef: kind: GitRepository name: podinfo validation: client