secure:
postgresql:
database: immuta
ssl: true
onboarding:
postgresql:
database: immuta
If you store database credentials in a Kubernetes secret (secure.existingSecret.name), you must also add an ONBOARDING_DATABASE_URL key to that secret and set onboarding.existingSecret. Otherwise, the upgrade fails with onboarding.postgresql.password is required. See the Existing Kubernetes secrets section for more details.
secure:
ingress:
enabled: true
hostname: <immuta-fqdn>
ingressClassName: nginx
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: '64m'
helm.sh/resource-policy: "keep"
helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version <your-current-immuta-version>
gateway:
ingress:
enabled: false
helm template immuta oci://ocir.immuta.com/stable/immuta-enterprise --version 2026.2.2 -n <ns> -f immuta-values.yaml \
--show-only charts/secure/templates/guardrail-report-job.yaml | kubectl -n <ns> apply -f -
kubectl -n <ns> wait --for=condition=complete job/immuta-secure-guardrail-report --timeout=5m
kubectl -n <ns> logs job/immuta-secure-guardrail-report
kubectl -n <ns> delete job immuta-secure-guardrail-report
helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2026.2.2 --timeout 3h
kubectl -n <ns> get pods # all Running / Completed
kubectl -n <ns> get jobs # all Complete, incl. onboarding-db-migrator and temporal-cleanup
kubectl -n <ns> get ingress # <release>-secure still present
kubectl -n <ns> get deploy <release>-gateway # 1/1 ready
kubectl -n <ns> patch ingress <release>-secure --type=json -p '[
{"op":"replace","path":"/spec/rules/0/http/paths/0/backend/service/name","value":"<release>-gateway"},
{"op":"replace","path":"/spec/rules/0/http/paths/0/backend/service/port","value":{"number":8000}}
]'
kubectl -n <ns> logs deploy/<release>-gateway --since=1m | grep -c DownstreamStatus
secure:
ingress:
enabled: true
hostname: <immuta-fqdn>
ingressClassName: nginx
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: '64m'
helm.sh/resource-policy: "keep"
helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version <your-current-immuta-version>
gateway:
ingress:
enabled: true
hostname: immuta.example.com
ingressClassName: alb
annotations: { ...your ALB annotations, cert ARN, etc... }
helm template immuta oci://ocir.immuta.com/stable/immuta-enterprise --version 2026.2.2 -n <ns> -f immuta-values.yaml \
--show-only charts/secure/templates/guardrail-report-job.yaml | kubectl -n <ns> apply -f -
kubectl -n <ns> wait --for=condition=complete job/immuta-secure-guardrail-report --timeout=5m
kubectl -n <ns> logs job/immuta-secure-guardrail-report
kubectl -n <ns> delete job immuta-secure-guardrail-report
helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2026.2.2 --timeout 3h
helm template immuta oci://ocir.immuta.com/stable/immuta-enterprise --version 2026.2.2 -n <ns> -f immuta-values.yaml \
--show-only charts/secure/templates/guardrail-report-job.yaml | kubectl -n <ns> apply -f -
kubectl -n <ns> wait --for=condition=complete job/immuta-secure-guardrail-report --timeout=5m
kubectl -n <ns> logs job/immuta-secure-guardrail-report
kubectl -n <ns> delete job immuta-secure-guardrail-report
| Before upgrade (always required policy) | After upgrade (guardrail policy) | |
|---|---|---|
| Policy | Subscribe users when user is a member of group Finance on all data sources tagged sales. | Prevent users from gaining access unless user is a member of group Finance on all data sources tagged sales. |
| Result | Everyone from Finance gets subscribed | Nobody gets subscribed, but if there is any grant policy trying to give access to someone that is not in Finance, those users will be blocked |
FinanceMarketingHRFinanceFinanceMarketingMarketingHRHRUsers will be subscribed to the data source
when they are member of group Finance AND Marketing AND HR.
Users will be subscribed to the data source when they are (a member of group Finance OR Marketing OR HR)
AND
(a member of group Finance AND Marketing AND HR).
SalesManufacturingSalesManufacturingManufacturingUsers will be subscribed they are a member of group Sales AND Manufacturing.
In this example, the policies are combined with AND because there is an always required policy in play.
| Users will be subscribed to this data source when they are (a member of group `Sales` OR `Manufacturing`) AND (a member of group `Manufacturing`). | In this scenario, the final access criteria **does not remain the same**: A user will now get subscribed to this data source as long as they are a member of group `Manufacturing`; being a member of group `Sales` is no longer a hard requirement. The access criteria for this data source has become less restrictive, potentially leading to more users getting subscribed to this data source after the upgrade. Given that this scenario leads to a change in access, you have the following options: 1. Do nothing and accept the change in behavior for affected data sources 2. Change the shared responsibility policy into an always required policy, which will turn the data source into a [scenario 1 migration case](#migration-scenario-1-multiple-always-required-policies-applied-to-a-data-source) instead. Contact your Immuta representative if you would like receive guidance in making the right decision for your case."subscriptionType": "policy""shareResponsibility": true
"subscriptionType": "policy""shareResponsibility": true
"subscriptionType": "policy""shareResponsibility": false
"subscriptionType": "policy""shareResponsibility": true
"subscriptionType": "guardrail""shareResponsibility": true
"subscriptionType": "guardrail""shareResponsibility": false
"subscriptionType": "guardrail""shareResponsibility": false
"subscriptionType": "guardrail""shareResponsibility": false