gopass is a simple but powerful password manager for your terminal.

Password store template for teams

This repository contains a base template for a password store repository to be used by teams.

It contains:

A README.md to adapt to your team
A script to setup a unique alias based on the directory name.
A Makefile with some common tools

Viele DevOps-Teams gehen mit ihnen anvertrauten Credentials wie Passwörtern oder Zertifikaten sorglos um. Verglichen mit Slack Tokens, die versehentlich auf GitHub exponiert wurden, ist ein Schaden bei Infrastructure as Code schnell deutlich größer. Immerhin ist das Äquivalent eines Rechenzentrums bedroht.

Alte Ansätze wie versiegelte Umschläge im Safe oder fein abgestimmte Active-Directory- oder LDAP-Integrationen funktionieren in der verteilten und dynamischen DevOps-Welt oft nicht mehr. Leider gibt es aber auch noch kein wirklich etabliertes "leichtgewichtiges" Set von Werkzeugen für das Credential-Management. Was also tun, wenn das eigene DevOps-Team schnell wächst, die Zahl der verwendeten Tools schon weit zweistellig ist und die Komplexität dennoch beherrschbar bleiben soll? Gesucht ist eine Möglichkeit für Credential-Management, die zu den verwendeten Tools passt und gleichzeitig die dadurch zusätzlich eingeführte Komplexität niedrig hält.

Menschen, die in diesem frühen September 2018 in meinem Schwabinger Kaffeehaus nach wenigen Minuten eines Leseversuchs ihre einst so geliebte SZ zu Seite legen, fragen mich immer wieder - da sie gehört haben, dass ich für eine sehr lange Zeit für viele nennenswerte Printorgane gearbeitet habe, was eigentlich aus uns Journalisten geworden ist, wann das "irgendwie" alles begann mit dem sittlichen Zerfall und ob sich die Branche irgendwann einmal wieder von dieser Implosion erholen wird und ob das eine Delle ist oder eine Art Grippe, wie Aids halt und man das wieder in den Griff bekommt.

But there is a major issue with both Signal and WhatsApp: Your account is tied to your phone number.

While exploring tooling for Kubernetes I had need for schemas to describe the definition files, and went looking for something that didn't require either kubectl or similar installed or even a working Kubernetes installation.

It turns out that the OpenAPI specification contain this information, but not in a particularly usable format for tools which might just want a raw JSON Schema.

This repository contains a set of schemas for most recent Kubernetes versions. For each specified Kubernetes versions you should find four different flavours:

vX.Y.Z - URL referenced based on the specified GitHub repository
vX.Y.Z-standalone - de-referenced schemas, more useful as standalone documents
vX.Y.Z-local - relative references, useful to avoid the network dependency
vX.Y.Z-strict - prohibits properties not defined in the schema

Note that the Kubernetes API allows additional properties to be submitted, but kubectl acts like the strict flavour above.

jsonschema is an implementation of JSON Schema for Python (supporting 2.7+ including Python 3).

Features

• Full support for Draft 6, Draft 4 and Draft 3
• Lazy validation that can iteratively report all validation errors.
• Small and extensible
• Programmatic querying of which properties or items failed validation.

Devicon is a set of icons representing programming languages, designing & development tools. You can use it as a font or directly copy/paste the svg code into your project.

Romana is a network and security automation solution for cloud native applications. Romana automates the creation of isolated cloud native networks, secures applications using microsegmentation and enforces access control policies on all endpoints, wherever they run.

Romana is network agnostic and secures applications using standard networking techniques so they can be deployed easily on public and private clouds, and even across the Internet.

Applications that run with Romana are easier to operate and deliver higher performance than when using a virtual network overlay. With Romana, an overlay is never required, even across availability zone boundaries. Romana’s innovative approach enables seamless hybrid cloud deployment and lets container orchestration systems transparently scale capacity across private and public clouds worldwide.

Integration with Kubernetes and other cloud orchestration systems lets application developers use their existing tools and workflow to secure their applications with the deployment flexibility they need.

Romana is all open source and is deployed successfully today on servers running thousands of container workloads by operators of some of the largest on-line applications. Romana lets you deploy cloud native applications securely on isolated networks with policy based control. Romana runs in any IaaS, so developers running Kubernetes in a public cloud now have a way to apply network and security policies to all pod communications.

n der Welt der Softwareentwicklung existiert ein grauenhafter Ort namens “Dependency Hell”. Um so größer ein Projekt wird und je mehr Pakete in die Software integriert werden, desto wahrscheinlicher ist es, dass dieser fürchterliche Ort eines Tages betreten wird.

In Projekten mit vielen Abhängigkeiten kann das Aktualisieren abhängiger Pakete schnell zum Albtraum werden. Sind die Abhängigkeitsspezifikationen des Pakets zu strikt, besteht die Gefahr des “Version Lock” (die Unfähigkeit ein Paket zu aktualisieren, ohne, dass alle abhängigen Pakete dieses Pakets ebenfalls aktualisiert werden müssen). Wenn die Abhängigkeiten des Pakets allerdings zu lasch definiert sind, wird sehr wahrscheinlich ein Problem, das sich “Version Promiscuity” nennt (das Paket gibt vor, mit mehr zukünftigen Versionen seiner abhängigen Pakete kompatibel zu sein, als angemessen ist), eintreten. Dependency Hell bezeichnet die Situation, in der entweder Version Lock oder Version Promiscuity, oder beides den Entwicklungsprozess des Projekts beeinträchtigt.

Als Lösung für dieses Problem schlage ich ein einfaches Regelwerk vor, welches definiert wie Versionsnummern gewählt und erhöht werden. Diese Regeln basieren auf bereits existierenden und weit verbreiteten Verfahren, welche sowohl bei der Entwicklung von Closed- als auch von Open-Source Software verwendet werden, aber beschränken sich nicht zwingend auf diese. Um dieses System nutzen zu können, muss zuerst eine öffentliche API definiert werden. Diese kann entweder in Form einer Dokumentation existieren oder durch den Code selbst erzwungen werden. Egal auf welche Art und Weise die API umgesetzt wird, es ist wichtig, dass sie übersichtlich und präzise ist. Sobald die öffentliche API erstellt wurde, werden Änderungen an dieser durch bestimmten Veränderungen an der Versionsnummer vermittelt. Nimm ein Versionsnummernformat von X.Y.Z (Major.Minor.Patch) an. Bei Einführung von Bugfixes, welche die öffentliche API nicht beeinflussen, wird die Patch Version erhöht, API-kompatible Ergänzungen oder Änderungen erhöhen die Minor Versionsnummer, und Änderungen, welche nicht kompatibel zur aktuellen öffentlichen API sind, erhöhen die Major Version.

Ich nenne dieses System “Semantic Versioning”. Versionsnummern, die nach diesem Schema gewählt und erhöht werden, geben direkten Aufschluss über den entsprechenden Code und was sich von einer zur anderen Version verändert hat.

Helm helps you manage Kubernetes applications — Helm Charts helps you define, install, and upgrade even the most complex Kubernetes application.

Charts are easy to create, version, share, and publish — so start using Helm and stop the copy-and-paste madness.

The latest version of Helm is maintained by the CNCF - in collaboration with Microsoft, Google, Bitnami and the Helm contributor community.

kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster.

kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile completely in userspace. This enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster.

This guide is for people who want to craft a custom Kubernetes cluster. If you can find an existing Getting Started Guide that meets your needs on this list, then we recommend using it, as you will be able to benefit from the experience of others. However, if you have specific IaaS, networking, configuration management, or operating system requirements not met by any of those guides, then this guide will provide an outline of the steps you need to take. Note that it requires considerably more effort than using one of the pre-defined guides.

This guide is also useful for those wanting to understand at a high level some of the steps that existing cluster setup scripts are making.

MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.

Why?

Kubernetes does not offer an implementation of network load-balancers (Services of type LoadBalancer) for bare metal clusters. The implementations of Network LB that Kubernetes does ship with are all glue code that calls out to various IaaS platforms (GCP, AWS, Azure…). If you’re not running on a supported IaaS platform (GCP, AWS, Azure…), LoadBalancers will remain in the “pending” state indefinitely when created.

Bare metal cluster operators are left with two lesser tools to bring user traffic into their clusters, “NodePort” and “externalIPs” services. Both of these options have significant downsides for production use, which makes bare metal clusters second class citizens in the Kubernetes ecosystem.

MetalLB aims to redress this imbalance by offering a Network LB implementation that integrates with standard network equipment, so that external services on bare metal clusters also “just work” as much as possible.

This page explains two different approaches to setting up a highly available Kubernetes cluster using kubeadm:

With stacked masters. This approach requires less infrastructure. etcd members and control plane nodes are co-located.
With an external etcd cluster. This approach requires more infrastructure. The control plane nodes and etcd members are separated.

Your clusters must run Kubernetes version 1.11 or later. You should also be aware that setting up HA clusters with kubeadm is still experimental. You might encounter issues with upgrading your clusters, for example. We encourage you to try either approach, and provide feedback.

Traditional SDNs are complex, making them hard to deploy and troubleshoot. Calico removes that complexity, with a simplified networking model designed for the demands of today's cloud-native applications.

Unlike SDNs that require a central controller, limiting scalability, Calico is built on a fully distributed, scale-out architecture. So it scales smoothly from a single developer laptop to large enterprise deployments.

Defining secure network policy used to be reserved for skilled network engineers. Calico's powerful micro-segmentation capabilities build on a simple policy language that naturally expresses the developer's intent.

The goal of fpm is to make it easy and quick to build packages such as rpms, debs, OSX packages, etc.

fpm, as a project, exists to help you build packages, therefore:

If fpm is not helping you make packages easily, then there is a bug in fpm.
If you are having a bad time with fpm, then there is a bug in fpm.
If the documentation is confusing, then this is a bug in fpm.

If there is a bug in fpm, then we can work together to fix it. If you wish to report a bug/problem/whatever, I welcome you to do on the project issue tracker.

You can find out how to use fpm in the documentation.

You can learn how to install fpm on your platform in the installation guide.

If you have questions, join us on the kubernetes slack, channel #kubespray.

• Can be deployed on AWS, GCE, Azure, OpenStack, vSphere, Oracle Cloud Infrastructure (Experimental), or Baremetal
• Highly available cluster
• Composable (Choice of the network plugin for instance)
• Supports most popular Linux distributions
• Continuous integration tests

Fluent Bit is an open source and multi-platform Log Processor and Forwarder which allows you to collect data/logs from different sources, unify and send them to multiple destinations. It's fully compatible with Docker and Kubernetes environments.

Fluent Bit is written in C, have a pluggable architecture supporting around 30 extensions. It's fast and lightweight and provide the required security for network operations through TLS.