Deploy Ranger with Kubernetes #
This topic covers deploying a minimally customized Ranger instance with the Ranger Helm chart. Ranger optionally provides RBAC to SEP.
This topic assumes you are familiar with Ranger, as well as with Helm charts and Kubernetes (k8s) tools such as
kubectl
. Ensure that you are familiar with the
following Starburst Enterprise Kubernetes topics before configuring and
deploying Ranger:- Kubernetes best practices
- Kubernetes requirements
Overview #
Global access control in Starburst Enterprise platform (SEP) allows you to create, manage, and store access control policies for objects that SEP has access to, including:
- Catalogs
- Schemas
- Views
- Tables
- Columns
- Rows
- Procedures
- Session properties
Ranger access control policies can grant or revoke access to any of the above mentioned objects, and are stored in a backing PostgreSQL database.
Ranger is deployed via a separate Kubernetes (K8s) Helm chart. You can configure
multiple Starburst clusters to use the same Ranger instance. Once
deployed, Ranger is available within the cluster and can be accessed internally
using http://ranger:6080
. External access is controlled via the DNS configured
for Ranger ingress.
Configure Ranger #
There are several top-level nodes in the Ranger Helm chart that you must modify for a minimum Ranger configuration:
admin:
usersync:
database:
If you are using TLS, this must also be considered. This section covers getting started with these four configuration steps. Our reference documentation provides details about the content of the Ranger Helm chart, including yaml sections not discussed here.
As with SEP, we strongly suggest that you initially deploy Ranger with the minimum configuration described in this topic, and ensure that it deploys and is accessible before making any additional customizations described in our reference documentation.
ranger-values.yaml
that is used in the
Helm upgrade
command.Before you begin #
Get the latest starburst-ranger
Helm chart as described in our installation
guide with the configured registry
access.
Configure the Ranger administration container #
The following values must be defined in the admin:
node of the Ranger Helm
chart:
- CPU resources for requests and limits - The defaults are sufficient for most environments; however, they must work with the instance type you are using.
- Memory resources for requests and limits - The defaults are sufficient for most environments; however, they must work with the instance type you are using.
- Passwords - You must supply all passwords in the
passwords:
node.
You can read more about the admin:
top-level node in our reference
documentation.
Configure Usersync #
Usersync automates the process of adding users to Ranger for policy enforcement by allowing the synchronization of users and groups from LDAP, including Active Directory.
At a minimum, the env:
properties in the top-level usersync:
node must be
defined correctly for your environment. The following snippet uses example
values:
env:
# Use RANGER__<property_name> variables to set Ranger install properties.
RANGER__SYNC_LDAP_URL: "ldap://ranger-ldap:389"
RANGER__SYNC_LDAP_BIND_DN: "cn=admin,dc=ldap,dc=example,dc=org"
RANGER__SYNC_LDAP_BIND_PASSWORD: "xx999xx999x"
RANGER__SYNC_LDAP_SEARCH_BASE: "dc=ldap,dc=example,dc=org"
RANGER__SYNC_LDAP_USER_SEARCH_BASE: "ou=users,dc=ldap,dc=example,dc=org"
RANGER__SYNC_LDAP_USER_OBJECT_CLASS: "person"
RANGER__SYNC_GROUP_SEARCH_ENABLED: "true"
RANGER__SYNC_GROUP_USER_MAP_SYNC_ENABLED: "true"
RANGER__SYNC_GROUP_SEARCH_BASE: "ou=groups,dc=ldap,dc=example,dc=org"
RANGER__SYNC_GROUP_OBJECT_CLASS: "groupOfNames"
For all Ranger Helm chart usersync properties, see our reference documentation.
Configure the PostgreSQL backing database #
The configuration properties for the PostgreSQL database which stores policy
information are found in the database:
top-level node. As a minimal
customization, you must ensure that the following are set correctly for your
environment:
database:
type: "internal"
internal:
port: 5432
databaseName: "ranger"
databaseUser: "ranger"
databasePassword: "RangerPass123"
databaseRootUser: "rangeradmin"
databaseRootPassword: "RangerAdminPass123"
You may also configure volume:
persistence and resources, as well as the
resources:
for the backing database itself in the database:
node. For a
complete list of available backing database properties, see our reference
documentation.
Configure TLS (optional) #
If your organization uses TLS, you must enable and configure Ranger to work with it. The most straightforward way to handle TLS is to terminate TLS at the load balancer or ingress, using a signed certificate. We strongly suggest this method, which method requires no additional configuration in Ranger. Ranger can also be configured to listen on HTTPS directly.
If you choose not handle TLS using those methods, you can instead configure it
in the
usersync:
and
expose:
top-level nodes of the Ranger Helm chart. The following snippets show the
nodes of each of these sections:
usersync:
tls:
# optional truststore containing CA certificate for ldap server
truststore:
# existing secret containing truststore.jks key
secret:
# password to truststore
password:
expose:
type: "[clusterIp|nodePort|loadBalancer|ingress]"
You must refer to our reference documentation for full details on configuring
each of these
types.
The default expose:
type is clusterIp
. However, this is not suitable for
production environments. If you need help choosing which type is best, refer to
the expose:
documentation
for SEP.
Deploy Ranger #
When Ranger is configured, run the following command to deploy it. In this
example, the minimal values YAML file with the registry
credentials named registry-access.yaml
is used along with the ranger-values.yaml
containing the Ranger customizations:
$ helm upgrade ranger starburst/starburst-ranger \
--install \
--values ./registry-access.yaml \
--values ./ranger-values.yaml
Next steps #
- Read about SEP and Ranger
- Complete your Ranger configuration
Is the information on this page helpful?
Yes
No