I am using the RabbitMQ Kubernetes operator for a dev-instance and it works great. What isn't great is that the credentials generated by the operator are different for everyone on the team (I'm guessing it generates random creds upon init).
Is there a way to provide a secret and have the operator use those credentials in place of the generated ones?
Yaml:
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
name: rabbitmq-cluster-deployment
namespace: message-brokers
spec:
replicas: 1
service:
type: LoadBalancer
Ideally, I can just configure some yaml to point to a secret and go from there. But, struggling to find the documentation around this piece.
Example Username/Password generated:
user: default_user_wNSgVBIyMIElsGRrpwb
pass: cGvQ6T-5gRt0Rc4C3AdXdXDB43NRS6FJ
I figured it out. Looks like you can just add a secret configured like the below example and it'll work. I figured this out by reverse engineering what the operator generated. So, please chime in if this is bad.
The big thing to remember is the default_user.confg setting. Other than that, it's just a secret.
kind: Secret
apiVersion: v1
metadata:
name: rabbitmq-cluster-deployment-default-user
namespace: message-brokers
stringData:
default_user.conf: |
default_user = user123
default_pass = password123
password: password123
username: user123
type: Opaque
rabbitmq-cluster-deployment-default-user comes from the Deployment mdatadata.name + -default-user (see yaml in question)
Related
I have a number of repeated values in my kubernetes yaml file and I wondering if there was a way I could store variables somewhere in the file, ideally at the top, that I can reuse further down
sort of like
variables:
- appName: &appname myapp
- buildNumber: &buildno 1.0.23
that I can reuse further down like
labels:
app: *appname
tags.datadoghq.com/version:*buildno
containers:
- name: *appname
...
image: 123456.com:*buildno
if those are possible
I know anchors are a thing in yaml I just couldn't find anything on setting variables
You can't do this in Kubernetes manifests, because you need a processor to manipulate the YAML files. Though you can share the anchors in the same YAML manifest like this:
---
apiVersion: v1
kind: ConfigMap
metadata:
name: &cmname myconfig
namespace: &namespace default
labels:
name: *cmname
deployedInNamespace: *namespace
data:
config.yaml: |
[myconfig]
example_field=1
This will result in:
apiVersion: v1
data:
config.yaml: |
[myconfig]
example_field=1
kind: ConfigMap
metadata:
creationTimestamp: "2023-01-25T10:06:27Z"
labels:
deployedInNamespace: default
name: myconfig
name: myconfig
namespace: default
resourceVersion: "147712"
uid: 4039cea4-1e64-4d1a-bdff-910d5ff2a485
As you can see the labels name && deployedInNamespace have the values resulted from the anchor evaluation.
Based on your use case description, what you would need is going the Helm chart path and template your manifests. You can then leverage helper functions and easily customize when you want these fields. From my experience, when you have an use case like this, Helm is the way to go, because it will help you customize everything within your manifests when you decide to change something else.
I guess there is a similar question with answer.
Please check below
How to reuse an environment variable in a YAML file?
In my Kubernetes cloud I do have FluxCD to manage all components. FluxCD is using SOPS to decrypt all the passwords. This is resulting in a declaration like this:
---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
name: load-balancer-controller
namespace: flux-system
spec:
interval: 1m
ref:
branch: main
url: https://github.com/fantasyaccount/load-balancer-controller.git
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
name: load-balancer-controller
namespace: flux-system
spec:
decryption:
provider: sops
secretRef:
name: sops-gpg
interval: 1m
path: "./deployment"
prune: true
sourceRef:
kind: GitRepository
name: load-balancer-controller
Within the load-balancer-controller repo I can use SOPS encrypted secrets. That is clear for me.
However, is it possible to use SOPS as well for encrypting the secret token to have access to the repo itself? I know I can use kubectl create secret ... to add the secret token to Kubernetes as well, but that is now what I want. I would like to use a SOPS encrypted token here as well.
The challenge in encrypting the secret for the initial GitRepository, is to then define what the cluster provisioning process would look like, as this represents a bit of a chicken-egg problem.
One way I can see this working, is to install Flux with a source that supports contextual authentication, such as Bucket. With that, you could store in an S3 Bucket the encrypted Git secret, the GitRepository to current repository, and the Kustomization that applies it to your cluster.
Here's more information about the contextual authentication for EKS:
https://fluxcd.io/docs/components/source/buckets/#aws-ec2-example
Just notice that with this approach, your cluster deployment pipeline would have to store your GPG key, as you would need to deploy that secret before (or soon after) you install Flux into the cluster.
So I want to create multiple postgresql databases in the kubernetes deployment.
I tried with the below configMaps configuration but the databases are not being created. I tried to log into the postgres db pod with one of the database names I used in the configMaps but it say's the databse doesn't exist.
method 1:
apiVersion: v1
kind: ConfigMap
metadata:
name: hydra-kratos-postgres-config
labels:
app: hydra-kratos-db
data:
postgres.db.user: pguser
postgres.db.password: secret
postgres.db.name:
- postgredb1
- postgredb2
- postgredb3
method 2:
apiVersion: v1
kind: ConfigMap
metadata:
name: hydra-kratos-postgres-config
labels:
app: hydra-kratos-db
data:
POSTGRES_USER: pguser
POSTGRES_PASSWORD: secret
POSTGRES_MULTIPLE_DATABASES:
- kratos
- hydra
Would appreciate any suggestions on this. Thank you.
I assume you are using official Postgres image - by default it doesn't support multiple databases declaration on init. You could try building your own Postgres image like in this repo. If you create k8s deployment based on such image, I think there is a chance that your variable POSTGRES_MULTIPLE_DATABASES could work.
Let me know if you decide to try this.
I am using Kubernetes to deploy my grafana dashboard and I am trying to use Kubernetes Secrets for saving grafana admin-password .. Here is my yaml file for secret
apiVersion: v1
kind: Secret
metadata:
name: $APP_INSTANCE_NAME-grafana
labels:
app.kubernetes.io/name: $APP_INSTANCE_NAME
app.kubernetes.io/component: grafana
type: Opaque
data:
# By default, admin-user is set to `admin`
admin-user: YWRtaW4=
admin-password: "$GRAFANA_GENERATED_PASSWORD"
value for GRAFANA_GENERATED_PASSWORD is base64 encoded and exported like
export GRAFANA_GENERATED_PASSWORD="$(echo -n $PASSWORD | base64)"
where PASSWORD is a variable which i exported on my machine like
export PASSWORD=qwerty123
I am trying to pass the value of GRAFANA_GENERATED_PASSWORD to the yaml file for secret like
envsubst '$GRAFANA_GENERATED_PASSWORD' > "grafana_secret.yaml"
The yaml file after passing the base64 encoded value looks like
apiVersion: v1
kind: Secret
metadata:
name: kafka-monitor-grafana
labels:
app.kubernetes.io/name: kafka-monitor
app.kubernetes.io/component: grafana
type: Opaque
data:
# By default, admin-user is set to `admin`
admin-user: YWRtaW4=
admin-password: "cXdlcnR5MTIz"
After deploying all my objects i couldn't login to my dashboard using password qwerty123 which is encoded properly ..
But when i try to encode my password like
export GRAFANA_GENERATED_PASSWORD="$(echo -n 'qwerty123' | base64)"
It is working properly and i can login to my dashboard using the password qwerty123 ..
Looks like the problem occur when i encode my password using a variable ...
But i have encode my password using a variable
As mentioned in #Pratheesh comment, after deploy the grafana for the first time, the persistent volume was not deleted/recreated and the file grafana.db that contains the Grafana dashboard password still keeping the old password.
In order to solve, the PersistentVolume (pv) need to be deleted before apply the secret with the new password.
i'm playing around with knative currently and bootstrapped a simple installation using gloo and glooctl. Everything worked fine out of the box. However, i just asked myself if there is a possibility to change the generated url, where the service is made available at.
I already changed the domain, but i want to know if i could select a domain name without containing the namespace, so helloworld-go.namespace.mydomain.com would become helloworld-go.mydomain.com.
The current YAML-definition looks like this:
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
labels:
name: helloworld-go
namespace: default
spec:
template:
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go
env:
- name: TARGET
value: Go Sample v1
Thank you for your help!
This is configurable via the ConfigMap named config-network in the namespace knative-serving. See the ConfigMap in the deployment resources:
apiVersion: v1
data:
_example: |
...
# domainTemplate specifies the golang text template string to use
# when constructing the Knative service's DNS name. The default
# value is "{{.Name}}.{{.Namespace}}.{{.Domain}}". And those three
# values (Name, Namespace, Domain) are the only variables defined.
#
# Changing this value might be necessary when the extra levels in
# the domain name generated is problematic for wildcard certificates
# that only support a single level of domain name added to the
# certificate's domain. In those cases you might consider using a value
# of "{{.Name}}-{{.Namespace}}.{{.Domain}}", or removing the Namespace
# entirely from the template. When choosing a new value be thoughtful
# of the potential for conflicts - for example, when users choose to use
# characters such as `-` in their service, or namespace, names.
# {{.Annotations}} can be used for any customization in the go template if needed.
# We strongly recommend keeping namespace part of the template to avoid domain name clashes
# Example '{{.Name}}-{{.Namespace}}.{{ index .Annotations "sub"}}.{{.Domain}}'
# and you have an annotation {"sub":"foo"}, then the generated template would be {Name}-{Namespace}.foo.{Domain}
domainTemplate: "{{.Name}}.{{.Namespace}}.{{.Domain}}"
...
kind: ConfigMap
metadata:
labels:
serving.knative.dev/release: "v0.8.0"
name: config-network
namespace: knative-serving
Therefore, your config-network should look like this:
apiVersion: v1
data:
domainTemplate: {{ '"{{.Name}}.{{.Domain}}"' }}
kind: ConfigMap
metadata:
name: config-network
namespace: knative-serving
You can also have a look and customize the config-domain to configure the domain name that is appended to your services.
Assuming you're running knative over an istio service mesh, there's an example of how to use an Istio Virtual Service to accomplish this at the service level in the knative docs.