When you are preparing your vault environment for production, you would want to implement the end-to-end tls setup as stated in the hashicorp vault production-ready documentation.

Setting resource quotas such as CPU and memory limits/requests is easier said than done.

But why do you need this in the first place?

hello everyone, okay, so I did something recently with GitHub action, re-wrote and optimized a workflow of 900+ lines back to 200+

Hii 👋, I am sure you want peace of mind too, haha

Well, there is no way you would be discussing container supply chain security without talking about the signing of container images.

You probably handling your manifest and deployment secrets in kube like this

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hashicorp-vault-k8s
  name: hashicorp-vault-k8s
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hashicorp-vault-k8s
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hashicorp-vault-k8s
    spec:
      containers:
      - image: busybox
        name:
        env:
        - name: API_KEY
          value: jduhdshieioieiisbbjsb
        - name: AWS_KEY
          value: 96859988gddjjdjds
        - name: WEBHOOK_SECRET
          value: jimjimjimokaynice

Yeah, being doing the CI/CD implementations via github workflow lately and I am also trapped in the process of making commits to trigger the workflows or better still making empty commits, haha.

Almost everyone knows how to use .gitignore, the git file that helps in keeping sensitive files like .env out of the tracking, commit, and pushing process, and also unwanted folders like node_modules and all.

But do you know secrets, hardcoded credentials, and API aren't easy to deal with using a .gitignore file? you don't want to keep your config.js or config.go file out of the commit process, these are essential files to your project.

For someone who just started writing Go, I have no idea about //go:embed feature which came with the released version: 1.16.

A project I was working on recently led to discoveries.

Documentation is a vital part of any open source project or software.

It is the entry point or a fall back option for users of any open source project or software to read usage, installation instructions, to fix issues and learn more about the project.

Before we start, I will like to say, All these programs listed are not mandatory for you to contribute to open source.

But you can contribute to open source even if you don't get selected for these programs, you can always contribute to open source programs anytime you want.