Security in terms of containers/Kubernetes

All cloud providers and self defined security tools which works on the principles of IAM, policies, RBAC while network part has WAF, security groups Network Access Control List, load Balancers and different sessions of the TCP protocol.
For authentication into Kubernetes containers there are security measures are mostly focused on service accounts and Role based accessed etc to provide security policies , also kube config file can be created in front of every different user buts it can be easily accessed and changed.

So for better Container security a Custom Kubernetes Client is created which gives a particular type of access to a user for a specified task only.

The above diagram states the end user will just have a custom binary file from the admin he just needs to execute it.
Below are the steps to create the custom executable binary for implementing this secure Kubernetes access model.

1. Administrator-Defined Task Script (.sh file):

   • The administrator will create a shell script (.sh) that contains the specific curl command to retrieve information about a particular pod.

   • This script will not be directly executable by engineers; it will only serve as a building block for the next step.

2. Go Client (.go file):

   • The .sh script will be encapsulated within a Go client (.go file).

   • The Go client will read the .sh script and execute it when needed.

   • The Go client will also handle any additional logic, such as error handling and token validation.

3. Building the Go Binary:

   • To create a binary executable from the Go client, follow these steps:

       # Compile the Go code into an executable binary
       go build -o my-kube-client main.go
     

   • This will generate an executable binary named my-kube-client.

4. Usage by End Users:

   • End users (engineers) will receive the compiled binary (my-kube-client).

   • When they run the binary, it will execute the embedded curl command from the .sh script.

   • The binary will only allow access to the specific pod defined by the administrator.

5. Security Considerations:

   • Even if an engineer tries to reverse-engineer the binary, they won't be able to add additional curl commands to access other pods or deployment details.

   • Why? Because the binary relies on the administrator's access token (which is not embedded in the binary) to authenticate with the Kubernetes API server.

   • Without the token, any unauthorized requests will fail.

6. Token-Based Authentication:

   • The administrator's token should be passed to the Go client at runtime (e.g., via environment variables or configuration files).

   • The Go client will use this token to authenticate with the Kubernetes API server.

   • Make sure to keep the token secure and limit its distribution to authorized personnel only.