Hackerproof injection of secrets in kubernetes where none but your apps can use variables & secrets

 Okay, okay. It is not exactly hacker*proof* but definitely hacker resistant (you know like water resistant but not water proof). When we inject secrets into pods either via 

1. mounting, 
2. setting environment variables
3. using a helm values file with secrets and env vars
4. using CICD to inject while deployment
5. most tidious way: read from vault but this requires a role_id, secret_id of vault to be against set in pod as environment variable or some other way. Circular problem.

We stumbled upon a problem which actually ended up as a solution for our longterm question. How to hide secrets from a hacker or a rogue app which does ssh to the pod. If I am a hacker, I have ssh access to the pod, then I can see all secrets and environment variables. Can i set them up where only app can see it and nobody can?

example:

1. open up 2 shells
2. In shell 1 open your bashrc file, set some export or env vars and save.
3. Do `. /path/to/bashrc fiile' (notice the dot and a space after it)
4. In shell 1 you can access your new environment variable
5. In shell you cant or wont

example:

1. open up 2 shells
2. in shell one set an environment variable in the shell export xyz=abc and see if you can access it. you do.
3. In shell 2 you cant access the same.

Solution based on the above.

1. Mount secrets via vault or some place to some location in the pod /path/to/my/mount/vaultsecrets
2. In your entrypoint.sh file for your app, somewhere before you start your app, add `. /path/to/my/mount/vaultsecrets` 

Now when your pod on first boot, runs the entrypoint.sh, it sources all vars from your mount point and then starts your app in the same tty shell which means only this shell can access these environment variables and not the entire OS.

I had this secret injection employed with helm yaml file and I was itching for a more secure option to ensure nobody sees the secrets even if they connect to the pod but when we migrated from gitlab to github and github actions, my associate opted in this sidecar injection along with the helm yaml we had. It seems this unintended parallele secret injection via sidecar came as a blessing.

gotcha: So a hacker can literally manually run the command in the point no.2 and get the secrets?! Yes. but you can also add add another step after point. 2. Unmount that path. So now, you mounted the secrets, sourced it to a particular tty shell of the app and then unmounted it. 

VMs (Virtual Machines) on k8s with kube-virt against VMs on openstack or hypervisors

Virtual Machines (VMs) have been a popular way of deploying and running applications for many years. With the advent of cloud computing and the need for scalable, highly available infrastructure, VMs have found new homes in platforms like OpenStack and Hypervisors. But with the rise of Kubernetes, VMs on Kubernetes with KubeVirt have become increasingly popular, offering several advantages over traditional VMs on Hypervisors and OpenStack.

1. Improved Resource Management: Kubernetes, with its powerful scheduler, ensures that VMs are efficiently deployed and resourced according to the requirements of the applications they host. This results in a more optimized and cost-effective deployment, as VMs are only given the resources they actually need, instead of being over-provisioned.

2. Enhanced Networking: KubeVirt integrates with the Kubernetes networking model, providing a powerful and flexible way to manage network connections between VMs and other components within a cluster. This allows for easy scaling and migration of VMs without having to worry about network configurations.

3. Improved Security: VMs on Kubernetes with KubeVirt can leverage Kubernetes security features, such as network segmentation, secrets management, and pod security policies, to provide a secure and controlled environment for deploying applications.

4. Easier Migration: One of the biggest benefits of VMs on Kubernetes with KubeVirt is that they can be easily migrated between clusters and across cloud providers. This makes it easier for organizations to move their applications to new infrastructure as needed, without having to worry about compatibility issues or reconfiguring network connections.

5. Increased Flexibility: KubeVirt provides a unified way to manage both VMs and containers within a single cluster, giving organizations greater flexibility in choosing the best deployment option for their applications. This allows for a more streamlined and efficient deployment process, as well as the ability to run legacy applications in a modern, scalable infrastructure.

In conclusion, VMs on Kubernetes with KubeVirt offer several key advantages over traditional VMs on Hypervisors and OpenStack, including improved resource management, enhanced networking, improved security, easier migration, and increased flexibility. As organizations look to modernize their infrastructure and move to the cloud, VMs on Kubernetes with KubeVirt are becoming an increasingly popular choice, offering a powerful and scalable platform for deploying applications.

SDLC with k8s

Software Development Life Cycle (SDLC) is a process of designing, developing, and deploying software applications. It involves various phases, including planning, analysis, design, development, testing, and deployment. With the increasing popularity of Kubernetes, organizations are looking for ways to integrate it into their SDLC process. Kubernetes, an open-source container orchestration system, can help simplify the deployment and management of complex applications. In this article, we will discuss the benefits of incorporating Kubernetes into the SDLC process and how it can help improve the overall software development process.

1. Improved Deployment Process Kubernetes makes it easier to deploy and manage complex applications. With Kubernetes, you can define and automate your deployment process, making it easier to deploy applications consistently and repeatedly. This helps to minimize downtime and reduces the risk of human error. Additionally, Kubernetes provides features such as rolling updates, which allow you to update your application without affecting the availability of your services.

2. Faster Testing With Kubernetes, you can easily spin up test environments in minutes, allowing you to test your application in a variety of scenarios. This speeds up the testing process and helps to catch bugs and issues early on in the development process. Additionally, Kubernetes provides features such as automatic rollbacks, which allow you to revert to a previous version of your application in case of a failure.

3. Improved Collaboration Kubernetes makes it easier for development teams to work together by providing a unified platform for deploying and managing applications. This helps to reduce the risk of conflicting changes and improves collaboration between developers, testers, and operations teams. Additionally, Kubernetes provides a centralized management system for applications, making it easier for teams to collaborate and manage their applications.

4. Scalability and Flexibility Kubernetes provides a scalable and flexible platform for deploying and managing applications. With Kubernetes, you can easily scale your applications up or down based on demand, making it easier to manage the resources needed for your applications. Additionally, Kubernetes provides features such as automatic scaling, which allows your applications to automatically scale based on the usage patterns.

5. Cost Savings By integrating Kubernetes into the SDLC process, organizations can reduce the time and cost associated with deploying and managing applications. With Kubernetes, you can automate the deployment and management process, reducing the need for manual intervention. Additionally, Kubernetes provides a unified platform for deploying and managing applications, reducing the need for multiple tools and systems.

In conclusion, incorporating Kubernetes into the SDLC process provides numerous benefits, including improved deployment processes, faster testing, improved collaboration, scalability and flexibility, and cost savings. By integrating Kubernetes into the SDLC process, organizations can improve the overall software development process and deliver better quality applications faster.

Static IP address for a VM on k8s via kube-virt

KubeVirt is an open-source project that allows you to run virtual machines (VMs) on top of Kubernetes. If you want to assign a static IP to a VM running in KubeVirt, you will need to configure the network settings for the VM.

You might be familiar with metallb loadbalancer on k8s. You create an ip pool or multiple ip pools and when a service requests an IP, It will auto assign the IP.

Similarly you create an ip pool here an ip pool, when you create VMs, They will automatically get one IP with kube virt.

Here are the steps to assign a static IP to a VM in KubeVirt:

1. Create a Network Attachment Definition (NAD) that specifies the static IP address you want to assign to the VM. For example: 

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: my-static-ip-network
spec:
  config: '{
      "cniVersion": "0.3.0",
      "name": "my-static-ip-network",
      "type": "ipvlan",
      "ipam": {
          "type": "host-local",
          "subnet": "10.244.0.0/16",
          "routes": [
              { "dst": "0.0.0.0/0" }
          ],
          "ranges": [
              [
                  {
                      "subnet": "10.244.0.0/24",
                      "gateway": "10.244.0.1"
                  }
              ]
          ],
          "config": [
              {
                  "subnet": "10.244.0.0/24",
                  "gateway": "10.244.0.1",
                  "ipMasq": true
              }
          ]
      }
  }'

    

       2. Apply the NAD to your Kubernetes cluster using kubectl apply:

kubectl apply -f my-static-ip-network.yaml 

      3. Update your VM definition to use the NAD. This can be done by adding a network section to the spec section of your VM definition. For example:

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  name: my-vm
spec:
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/vm: my-vm
    spec:
      domains:
        - type: kvm
          resources:
            requests:
              memory: 64M
          devices:
            interfaces:
            - name: eth0
              bridge: {}
              network: my-static-ip-network
              model: virtio
              macAddress: "52:54:00:12:34:56"

   4. Apply the updated VM definition to your Kubernetes cluster using kubectl apply: 

kubectl apply -f my-vm.yaml

Once the VM is started, it should be assigned the static IP address specified in the NAD. You can verify this by checking the IP address of the VM from within the VM or by using kubectl get pod to inspect the network configuration of the pod that represents the VM in Kubernetes.