Skip to content
Snippets Groups Projects
Commit f9bddbe3 authored by Mart van Santen's avatar Mart van Santen
Browse files

Merge branch '76-use-kratos-as-identity-manager' of...

Merge branch '76-use-kratos-as-identity-manager' of open.greenhost.net:/openappstack/single-sign-on into 76-use-kratos-as-identity-manager
parents 3bacbbd0 3a9ef3b7
No related branches found
No related tags found
1 merge request!46Add kratos container
# Admin IP/port
ip=127.0.0.1:8000
# Public IP/port
pip=127.0.0.1:8080
echo "Check if admin port can be reached:"
curl http://$ip/health/ready
echo "List identities:"
curl http://$ip/identities
echo "Get schema:"
curl http://$pip/schemas/default
echo "Create ID:"
json='{
"schema_id": "default",
"traits": {
"email": "test@greenhost.nl",
"name": {
"first": "Dave",
"last": "Stanley"
}
}
}'
curl -d "$json" -X POST http://$ip/identities
echo "Update an id"
id=af9b4abc-6308-48e2-abda-04e664487cf9
json='{
"schema_id": "default",
"traits": {
"email": "test@greenhost.nl",
"name": {
"first": "Dave",
"last": "Stanley"
},
"totp": "12345"
}
}
'
curl -d "$json" -X PUT http://$ip/identities/$id
# Introduction
kratos manage the user database. It has profiles of all users and keeps track
of lost password policies, welcome e-mails, TOTP (future), First, Last name etc.
Kratos is a flexible identity manager where our own "schema" can be defined with
the information we want for Stack Spin.
Kratos has a public API, which should be accessible for the world, and an admin API
which is ONLY accessible for our panel/board to manage users.
At the point of writing BOTH end-point are not public yet. We can use SSH port
forwards during development.
# Installation
The current kratos version is not yet merged to master. However, this does not
prevent us from developing already. To use / add the kratos backend, the
following needs to be done:
On your provisioning machine, make sure to checkout:
`git@open.greenhost.net:openappstack/single-sign-on.git`
Be sure to choose the kratos branch: `76-use-kratos-as-identity-manager`
Once this is all fetched, installation can be done with the following steps:
1. Suspend the automatic updating:
As we are gonna use a non-release version, the flux subsystem will rollback
changes to follow the released versions. However, during development we want
to prevent this. We can suspend the service with:
```
flux suspend source chart oas-single-sign-on
```
2. Make a backup of the current keys and configuration values. We needs those
when we install the new version of the `single-sign-on` helmchart:
```
helm get values single-sign-on -n oas > /to/a/path/my_cluster_values.yaml
```
3. Install the single-sign-on helmchart with kratos service
```
cd helmchart/single-sign-on
helm upgrade -f /to/a/path/my_cluster_values.yaml single-sign-on . -n oas --debug
```
This will install the latest version.
**Note**: Known issue, in some circumstances the installation fails because
kratos automigration kicks in too early. This needs more investigation. If you run
into this problem, try the following:
1. Open the file `helmchart/single-sign-on/values.yaml`
2. Set the `autoMigrate` on line 151 to `false`
3. Rerun the upgrade.
After successful upgrade, adjust the value back to `true` and rerun the upgrade
once again. As the PVC and database server are now up and running, the
automigration works as expected
It looks there is some kind of race condition, by first disabling the
automigration, the storage to store the database is created, so on the second run,
this race condition is not hit. This *should* not happen with kubernetes, so
maybe the cause is something else.
# Development
To develop, one needs access to kratos from the development system. A helper
script is available in this directory to setup the redirect the ports,
giving access to localhost port 8000 and 8080 for the admin/public port of
kratos.
```
./set-ssh-tunnel.sh `oas.example.com`
```
(the tunnel goes to the kubernetes node, so *not* to your provisioning machine.
kratos API is specified on their website:
https://www.ory.sh/kratos/docs/reference/api/
Some example can be found in:
```
./api-examples.sh
```
#!/bin/bash
host=$1
if [ "x$host" == "x" ]
then
echo "Please give host of kubernetes master as argument"
exit
fi
admin=`ssh $host -lroot kubectl get service -n oas|grep single-sign-on-kratos-admin | awk '{print $3'}`
public=`ssh $host -lroot kubectl get service -n oas|grep single-sign-on-kratos-public | awk '{print $3}'`
echo "Admin port will be at localhost:8000, public port will be at localhost:
8080"
ssh -L 8000:$admin:80 -L 8080:$public:80 root@$host
Please refer to the [online documentation](.../helmchart) Please refer to the [online documentation](.../helmchart)
This helmchart provides a first iteration of kratos services
as backend for user database storage.
The Kratos backend is not used by applications yet and is just
added to provide an infrastructure to develop the new frontend.
To apply this helmchart for testing and add kratos to your
stackspin cluster for development, follow those steps. Please
note, it can be needed to specify the right namesapce (`ex: -n oas`)
1. Suspend `core` kustomization
If this is applied on a Stack Spin cluster, then the update
mechanism will revert back to the old version at some point in time
so this needs to be suspended
```
flux suspend kustomization core
```
2. Backup you cluster values:
```
helm get values single-sign-on > cluster-values.yaml
```
3. Upgrade the helm chart to include kratos
```
helm upgrade -f ../cluster-values.yaml single-sign-on . --debug
```
3. Suspend
---
apiVersion: batch/v1
kind: Job
metadata:
name: {{ include "kratos.fullname" . }}-automigrate
{{- if .Release.Namespace }}
namespace: {{ .Release.Namespace }}
{{- end }}
labels:
{{ include "kratos.labels" . | indent 4 }}
annotations:
{{- with .Values.job.annotations }}
{{- toYaml . | nindent 4 }}
{{- end }}
helm.sh/hook-weight: "1"
helm.sh/hook: "post-install, post-upgrade"
helm.sh/hook-delete-policy: "before-hook-creation,hook-succeeded"
spec:
template:
{{- with .Values.job.annotations }}
metadata:
annotations:
{{- toYaml . | nindent 8 }}
{{- end }}
spec:
automountServiceAccountToken: {{ .Values.automountServiceAccountToken }}
containers:
- name: {{ .Chart.Name }}-automigrate
image: {{ include "kratos.image" . }}
imagePullPolicy: {{ include "kratos.imagePullPolicy" . }}
command: ["kratos"]
args: ["migrate", "sql", "-e", "--yes"]
env:
- name: DSN
valueFrom:
secretKeyRef:
name: {{ include "kratos.secretname" . }}
key: dsn
securityContext:
{{- toYaml .Values.securityContext | nindent 10 }}
{{- if .Values.deployment.extraVolumeMounts }}
volumeMounts:
{{ toYaml .Values.deployment.extraVolumeMounts | indent 10 }}
{{- end }}
restartPolicy: Never
{{- if .Values.deployment.extraInitContainers }}
initContainers:
{{ tpl .Values.deployment.extraInitContainers . | indent 8 }}
{{- end }}
{{- if .Values.deployment.extraVolumes }}
volumes:
{{ toYaml .Values.deployment.extraVolumes | indent 8 }}
{{- end }}
backoffLimit: 10
...@@ -79,6 +79,8 @@ postgresql: ...@@ -79,6 +79,8 @@ postgresql:
annotations: {} annotations: {}
postgresqlDatabase: kratos postgresqlDatabase: kratos
postgresqlUsername: kratos postgresqlUsername: kratos
# This will be overwritten during installation. If this helm
# chart is installed manual, this should be randomized or altered
postgresqlPassword: kratos postgresqlPassword: kratos
kratos: kratos:
...@@ -148,7 +150,9 @@ kratos: ...@@ -148,7 +150,9 @@ kratos:
} }
} }
autoMigrate: true # We included our own (forked) template to handle this job
autoMigrate: false
config: config:
identity: identity:
# This points to the filename in above identitySchemas section. # This points to the filename in above identitySchemas section.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment