I am looking at starting to manage clusters through RKE and Gitlab’s CICD process.
My biggest concerns are how to manage the *.rkestate file and the kube_cluster_config.yaml as I am hesitant to put those into source control.
Any insight would be great.
Thanks!
I agree, both contain data that you should consider as confidential. Not sure what you have available iro of a secrets store and a means to authenticate against that store, but where I work we use HashiCorp Vault to locate both of these. For CI/CD we use both Azure DevOps and Jenkins and it’s relatively straight forward to integrate Vault and other products. There are many other choices of course, encrypted S3 being another, but whatever you choose or are mandated to use, you are right to be very reluctant to put these in any regular SCM. At a push you could use you CI application itself, Jenkins has ‘credentials’ that, despite the name can be use for general name/value pairs. Azure DevOps has a secrets capability and I suspect most CI do also. In our case we prefer not to encourage ‘secrets sprawl’ and rather to consolidate all confidential data under one application, but YMMV.
Hi,
I’m struggling to connect an azure devops server running azure devops 2018 to a rancher OS cluster running into AWS.
I made attempt to use AD service connection but both kubeconfig and service account approach are not working.
You say you was able to connect rancher to ad: can you provide any clues about how you was able to do it ?
Basically I can’t go through the API authentication step: from the cluster API & Keys page I’ve one kubeconfig and many tokens but I dunno how to use them to successfully connect to the cluster from AD.
Thanks in advance