Saturday, March 11, 2023

KUBERNETES -CONFIGURE SECRETS






HOW TO MANAGE KUBERNETES BUILT IN SECRET 

Secret is an object that stores and manages sensitive information like API Keys, TSL certificates, Passwords etc. Secret can be manually created or automatically generated and it is configured in the environment variable, volume and manifest file. For example:

API_TOKEN: password123

ssl-cert :----CERTIFICATE---


TYPES OF SECRET

Built-in Type Usage
Opaque arbitrary user-defined data
kubernetes.io/service-account-token ServiceAccount token
kubernetes.io/dockercfg serialized ~/.dockercfg file (store cred for docker reg)
kubernetes.io/dockerconfigjson serialized ~/.docker/config.json file
kubernetes.io/basic-auth credentials for basic authentication
kubernetes.io/ssh-auth credentials for SSH authentication
kubernetes.io/tls data for a TLS client or server
bootstrap.kubernetes.io/token bootstrap token data


HOW DO WE MANAGE SECRETS IN KUBERNETES.

There are two ways to create a secret.

First, we define a "secret.yaml file" and this specifies the Kind, Metadata and Value.  The value has different numbers and its encrypted and coded in "Base64"

BASE64: This is used to encode data in email attachment and can represent binary data in JSON / XML format etc. 

NB: Yaml and Json - Are data exchange format.


HOW TO ENCODE YOUR SECRET:
You can use the "Base64" command line by applying the "echo command". The "-n" flag will prevent any additional code. We can connect with base64 to get the encoded string. See the below: 

$ echo -n "password123" | base64 - i - Gfjjrkwcmrlmcalm=


HOW TO CREATE A SECRET IN A CLUSTER.
In Kubernetes (K8), Kubectl support certain variants that does not require us to provision a file to store secret which is more secure. With this, you can pass your secret without having to encode it as shown below:  



HOW TO CONSUME SECRET AND REFERENCE IT

To achieve this, we identify two ways to consume secret in the cluster within an application. 
  • First, we can introduce it as an environment variables within the container when defining the POD/ CONTAINER in the manifest file. We define the "env" where the value should be pulled from a "reference" to that secret we created. Then, it can reference the key value pair. The application can run within the container to access the "process.env.API_TOKEN (JAVASCRIPT/PYTHON)"

  • The second method to consume secret is through "MOUNT VOLUME". This helps when we want to configure and consume sensitive information such as reading an SSL certificate manager.
We need to configure TWO THINGS in the manifest file. 
  • We declare the volume within the the pod that reference our secret.
  • We create a "volume mount with in the container specification"
To Note: The name of the volume and the volume mount MUST match. 



 
See next slide on RBAC in cluster. 😊

No comments:

Post a Comment

CONFIGURING A PHISHING CAMPAIGN IN MICROSOFT DEFENDER.

Configuring a phishing campaign in Microsoft Defender (specifically Microsoft Defender for Office 365) involves creating a simulated attack ...