Hello LEAF geniuses,
What’s the best way to get a Service Registry (deployed via leafctl) configured to use PostgreSQL (also deployed using leafctl)?
Thanks!
Chris
Hello, Chris.
Unfortunately, the LEAF Platform Service Registry pre-built image does not support using a PostgreSQL data store at this time.
You are welcome to create an enhancement request for it through the LEAF Service Desk.
Hello, Chris.
As of version 3.6.0-dev.1 of LEAFctl and the LEAF ServiceRegistry, you can perform the following to deploy a PostgreSQL data store and a ServiceRegistry configured to use it. Note that the following instructions are not intended for a production environment.
- Begin by ensuring your version of LEAFctl is
3.6.0-dev.1. Runleafctlto see the version printed.> leafctl LEAFctl Version: 3.6.0-dev.1 <-- Make sure the version is this or later - Deploy PostgreSQL as you normally would.
leafctl deploy postgresql - Create a new
values.yamlfile to contain our PostgreSQL configuration in.
a. The contents of thevalues.yamlwould look something like:leaf-service: selector: dataServiceType: sql sql: connectionDriverClass: org.postgresql.Driver connectionUrl: jdbc:postgresql://postgresql.postgresql.svc.cluster.local/postgres connectionUsername: postgres connectionPassword: cG9zdGdyZXM= dialect: com.leidos.leaf.dataobject.service.dao.sql.dialect.LeafPostgresDialect virtualService: | hosts: - "*" gateways: - istio-system/istio-ingressgateway http: - match: - uri: prefix: /service-registry/ rewrite: uri: / route: - destination: host: service-registry # Plus any other configuration you'd like to apply to the ServiceRegistry - Deploy the ServiceRegistry with LEAFctl using the
values.yamlabove.leafctl deploy service-registry -f <path-to-values-yaml>
That should deploy the LEAF ServiceRegistry with the configuration it needs to use PostgreSQL as its data store.
Additional Notes
- The
3.6.0-dev.1image of the LEAF ServiceRegistry should be backwards compatible with generated services back to3.3.0. However, we tested and found that even generated services on3.2.0could be registered with this latest ServiceRegistry. Since that is the case, there are no plans at this moment to port this feature back to older versions of the ServiceRegistry. If you encounter any problems with backwards compatibility, reach out and we can try to address them.
I’ll try it soon! Thanks so much!
Out of curiosity, why is this NOT intended for production?
Good question, Chris. I’ll try to provide some clarity as to why the instructions above weren’t necessarily intended for production, but I’d also like to add this preface. I’m personally not an expert when it comes to production environments, and there are others on the team who have a lot more experience in that realm.
Key Points
- LEAF recommends domain teams manage their deployment credentials in Kubernetes Secrets instead of allowing Helm charts to apply them.
- The configuration LEAFctl uses to deploy third party tools is not targeting a production environment, but rather a local development environment.
- The stand-alone image for the LEAF ServiceRegistry, by nature of being a pre-built image, doesn’t allow domains to add/configure authorization on transactions.
Details
Managing Credentials in Production
By placing credentials in values.yaml files and allowing Helm to apply them, they end up applied directly to K8s Deployment objects. Instead, K8s recommends the use of Secrets to store sensitive info like credentials. By using Secrets and referring to them in your K8s Deployment objects, you gain the ability to encrypt and otherwise protect the credentials.
To actually apply extra protection on Secrets, I have to refer to Kubernetes Documentation, but LEAF Platform Services does allow domains to specify Secrets for use with the our commonly used data stores such as MongoDB, PostgreSQL, and MySQL. To learn more, refer to the README of the leaf-service chart by running:
helm show readme leidos-leaf/leaf-service
I’ll go ahead and post the relevant section here for convenience.
### Secret Parameters
| Name | Environment Variable | Description | Value |
| -------------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ----- |
| `existingStorageSecret` | `N/A` | Define an existing storage secret to be used; defining this will remove any existing storage secret created by this chart | `""` |
| `existingTrustStoreSecret` | `N/A` | Define an existing trust store secret to be used; defining this will remove any existing trust store secret created by this chart | `""` |
## Storage Secret Creation
LEAF recommends that domains do not manage secrets through Helm for production
environments. A manual storage and/or trust store secret can be created and
referenced through the `existingStorageSecret` and `existingTrustStoreSecret`
parameters respectively.
The storage secret must have a key that equates to the following for MongoDB:
```txt
<MY_SERVICE_HELM_FULLNAME>-mongo-password
```
or the following for SQL data stores:
```txt
<MY_SERVICE_HELM_FULLNAME>-sql-connection-password
```
and a value that is a base64 encoded string.
The trust store secret must have a key that equates to the following:
```txt
<MY_SERVICE_HELM_FULLNAME>-trust-store-password
```
and a value that is a base64 encoded string.
If either parameter is set to a non-empty string, any
secrets previously created through this chart will be removed. If you do not set
a value for either parameter, a corresponding secret will be created for each.
For local development convenience, you can define a base64 encoded password for
your data store of choice in a `values.yaml` file:
```yaml
mongo:
...
password: <MY_BASE64_ENCODED_PASSWORD>
...
```
or
```yaml
sql:
...
connectionPassword: <MY_BASE64_ENCODED_PASSWORD>
...
```
If you have data store configuration in your `values.yaml` that does not define
a password, a secret will be created that has an empty string for the password.
The secret can then be edited through
[kubectl](https://kubernetes.io/docs/reference/kubectl/overview/),
[Lens](https://k8slens.dev/), etc.
LEAFctl Configuration
LEAFctl’s out-of-the-box configuration isn’t targeting production environments for a couple of reasons. First, to do so would make deploying to local machines infeasible with the amount of resources it would consume to have multiple replicas of everything and the required amount of memory and CPU to make a production environment reliable. Second, LEAF generally favors using hosted solutions for things like event brokers and data stores. Using services like MSK or DocumentDB should offload a significant portion of maintenance for those tools compared to hosting those tools yourself.
With that said, LEAFctl does support passing in custom configuration to the Helm charts it can deploy. Domains are able to create their own production yamls and deploy what LEAFctl offers to a production environment should they decide to go that route.
LEAF ServiceRegistry Auth
The LEAF ServiceRegistry does not apply authorization to any transaction it makes. Everything is done using the LEAF SYSTEM User, and, being a pre-built image that LPS publishes, domains cannot add a custom implementation of the LEAF Framework Services IDataObjectAuthorizationPolicy. Other things that domains cannot change about the ServiceRegistry include the base image used for the published image. That means if you would like to use an Ironbank, hardened image, then you are out of luck.
To address these shortcomings, LEAF Platform Services is slated to release library support and full LEAF Knowledge Base guidance to enable domain teams to build their own ServiceRegistries and JobManagers. This will empower domains to apply security and build the images as they require. Both will be a part of the upcoming 3.6.0 LTS release. LPS will still offer the pre-built images for convenience, but they’ll come with the same limitations mentioned above.
1 Like
Hi @hayden.curtis,
I’m beginning to incorporate the above version of leafctl. I’m concerned we’re going to have some backwards compatibility issues because my team has quite a set of scripts that call out to leafctl with all sorts of params. The first problem I’ve encountered is that I’m missing the --istio-https option for leafctl deploy. Do you know how I might work around this to get istio using https?
Hey, Chris.
Quick question: Which version of LEAFctl were you using previously?
Thanks.
3.3.2
Alright, my apologies for making this more difficult than it needed to be for you. Since leafctl is essentially just running a helm install command behind the scenes, and leafctl offers a fair amount of configuration, you should be able to install the new, updated service-registry Helm chart with older versions of leafctl. I led you to the newest release of leafctl because the default for the SR Helm chart is the new chart, but that was unnecessary.
Instead, the service-registry Helm chart version you’re looking for is 5.0.x. Using version 3.3.2 of leafctl, you can deploy the latest SR with support for PostgreSQL with the following command.
leafctl deploy service-registry --service-registry-version 5.0.x -f <path-to-values-yaml>
As in the post ServiceRegistry and PostgreSQL - #3 by hayden.curtis of this thread, you’ll want to create a values.yaml with the configuration to be applied to the service-registry Helm chart. If it helps, you can also apply the --dry-run flag to the command and leafctl will show you the command it intends to run.
I hope this helps, but definitely reach out if you still have problems.
1 Like
That worked! Thanks!
2 Likes