Database Access with Oracle Exadata
Teleport can provide secure access to Oracle Exadata via the Teleport Database Service. This allows for fine-grained access control through Teleport's RBAC.
In this guide, you will:
- Configure your Oracle Exadata database with mTLS authentication.
- Add the database to your Teleport cluster.
- Connect to the database via Teleport.
How it works
The Teleport Database Service authenticates to your self-hosted Oracle database using mutual TLS. Oracle trusts the Teleport certificate authority for database clients, and presents a certificate signed by either the Teleport database CA or a custom CA. When a user initiates a database session, the Teleport Database Service presents a certificate signed by Teleport. The authenticated connection then proxies client traffic from the user.
- Teleport Enterprise (Self-Hosted)
- Teleport Enterprise (Cloud)
Prerequisites
-
A running Teleport Enterprise cluster version 17.0.0-dev or above. If you want to get started with Teleport, sign up for a free trial.
-
The
tctl
admin tool andtsh
client tool.Visit Installation for instructions on downloading
tctl
andtsh
.
- Oracle Exadata server instance 19c or later.
- The
sqlcl
Oracle client installed and added to your system'sPATH
environment variable or any GUI client that supports JDBC Oracle thin client. - To check that you can connect to your Teleport cluster, sign in with
tsh login
, then verify that you can runtctl
commands using your current credentials. For example:If you can connect to the cluster and run thetsh login --proxy=teleport.example.com --user=email@example.comtctl statusCluster teleport.example.com
Version 17.0.0-dev
CA pin sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status
command, you can use your current credentials to run subsequenttctl
commands from your workstation. If you host your own Teleport cluster, you can also runtctl
commands on the computer that hosts the Teleport Auth Service for full permissions.
Step 1/6. Configure Oracle Exadata
This guide assumes default configuration of the Oracle Exadata system. In particular:
- Preconfigured TCPS listener.
- An existing database certificate in the grid wallet.
- A single Oracle Exadata VM is accessible to the
opc
user through SSH with a hostname demodb-vm. Repeat the steps to configure additional VMs. - The SCAN DNS name is demodb-vm-scan.exadatadomain.oke.oraclevcn.com.
Adjust the commands to match your configuration.
Update per-database configuration
Connect to the Oracle Exadata VM by logging in as the opc
user and then switch to the oracle
user:
ssh opc@demodb-vmsudo su - oracle
For each database-specific Oracle home, update the $ORACLE_HOME/network/admin/sqlnet.ora
file with the following entries:
SSL_CLIENT_AUTHENTICATION = TRUE
SQLNET.AUTHENTICATION_SERVICES = (ALL)
For example, if there is a database named spark
, the oracle
user should have access to the automatically generated /home/oracle/spark.env
file, which contains database-specific environment variables. After sourcing this file, the path $ORACLE_HOME/network/admin/sqlnet.ora
will point to the sqlnet.ora
file for the spark
database and its associated Oracle home.
Load environment variables for the 'spark' database
. spark.envEdit the configuration file at $ORACLE_HOME/network/admin/sqlnet.ora
...
Repeat these steps for each additional database or database home as required.
Configure Oracle user account
Your Oracle user accounts must be configured to require a valid client certificate.
- New user
- Existing user
Create new user:
CREATE USER alice IDENTIFIED EXTERNALLY AS 'CN=alice';
GRANT CREATE SESSION TO alice;
Alter existing user:
ALTER USER alice IDENTIFIED EXTERNALLY AS 'CN=alice';
This operation will void existing authentication methods like password. The certificate-based auth will become the sole method of authentication for this user.
Trust Teleport Database Client CA
Teleport uses mutual TLS authentication with Oracle Exadata. It must be configured with Teleport's certificate authority to be able to verify client certificates.
Export the Teleport Database Client CA on your local machine and copy it to target Oracle Exadata VM.
Export Teleport's database client certificate authority
tctl auth export --type=db-client > teleport-db-client-ca.crtCopy the CA to the Oracle Exadata VM
scp teleport-db-client-ca.crt opc@demodb-vm:/tmp/teleport-db-client-ca.crt
As the grid
user, update the grid TCPS wallet to trust the Teleport User Database CA.
Read the wallet password
mkstore -wrl /u01/app/oracle/admin/cprops/cprops_wallet -nologo -viewEntry grid_tcps_wallet_passwdgrid_tcps_wallet_passwd = <wallet password>Update the grid TCPS wallet; provide the password when prompted
orapki wallet add -wallet "/var/opt/oracle/dbaas_acfs/grid/tcps_wallets" -trusted_cert -cert /tmp/teleport-db-client-ca.crt
Enable TLS auth for grid listener
Adjust your grid listener configuration at $ORACLE_HOME/network/admin/listener.ora
to enable TLS auth with the following entry:
SSL_CLIENT_AUTHENTICATION = TRUE
Restart the listener
Once finished, restart the listener.
lsnrctl stoplsnrctl start
Step 2/6. Collect database configuration data
Export the built-in database certificate from Oracle. Teleport will use this certificate to verify the database connection.
Export the database certificate. Update the "-dn" parameter to match your actual setup.
orapki wallet export -wallet "/var/opt/oracle/dbaas_acfs/grid/tcps_wallets" -dn "CN=demodb-vm-scan.exadatadomain.oke.oraclevcn.com" -cert /tmp/oracle-server-certificate.crt
Save the /tmp/oracle-server-certificate.crt
file to a temporary location. The final location depends on the Teleport installation method, which will be detailed in the next step.
Check the TCPS address of the local listener. This address will be used by Teleport for the connection. In the example below, the address is 10.20.30.40:2484.
sqlplus / as sysdba...
SQL> SHOW PARAMETER local_listener;
. NAME TYPE VALUE
. -------------- ------ ------------------------------
. local_listener string (ADDRESS=(PROTOCOL=TCP)(HOST=10.20.30.40)(PORT=1521)),
. (ADDRESS=(PROTOCOL=TCPS)(HOST=10.20.30.40)(PORT=2484))
Step 3/6. Configure and Start the Database Service
Create Teleport join token
The Database Service requires a valid join token to join your Teleport cluster.
Run the following tctl
command and save the token output in /tmp/token
on the server that will run the Database Service:
tctl tokens add --type=db --format=textabcd123-insecure-do-not-use-this
Teleport Database Service
Install and configure Teleport where you will run the Teleport Database Service:
- Linux Server
- Kubernetes Cluster
Install Teleport on your Linux server:
-
Assign edition to one of the following, depending on your Teleport edition:
Edition Value Teleport Enterprise Cloud cloud
Teleport Enterprise (Self-Hosted) enterprise
-
Get the version of Teleport to install. If you have automatic agent updates enabled in your cluster, query the latest Teleport version that is compatible with the updater:
TELEPORT_DOMAIN=example.teleport.comTELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/automaticupgrades/channel/default/version | sed 's/v//')"Otherwise, get the version of your Teleport cluster:
TELEPORT_DOMAIN=example.teleport.comTELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/ping | jq -r '.server_version')" -
Install Teleport on your Linux server:
curl https://cdn.teleport.dev/install-v15.4.11.sh | bash -s ${TELEPORT_VERSION} editionThe installation script detects the package manager on your Linux server and uses it to install Teleport binaries. To customize your installation, learn about the Teleport package repositories in the installation guide.
On the host where you will run the Teleport Database Service, start Teleport with the appropriate configuration.
Note that a single Teleport process can run multiple different services, for
example multiple Database Service agents as well as the SSH Service or Application
Service. The step below will overwrite an existing configuration file, so if
you're running multiple services add --output=stdout
to print the config in
your terminal, and manually adjust /etc/teleport.yaml
.
Copy the Oracle Database certificate and make it available at
/var/lib/teleport/oracle-server-certificate.crt
on the Teleport Database Service host.
Run the following command to generate a configuration file at
/etc/teleport.yaml
for the Database Service. Update
example.teleport.sh to use the domain name of the Teleport Proxy
Service:
sudo teleport db configure create \ -o file \ --token=/tmp/token \ --proxy=example.teleport.sh:443 \ --name="oracle" \ --protocol=oracle \ --uri="10.20.30.40:2484" \ --ca-cert-file="/var/lib/teleport/oracle-server-certificate.crt" \ --labels=env=dev
Manually edit the generated config file to include tls.mode: verify-ca
.
The final entry for the oracle database will look similar to this:
db_service:
enabled: true
databases:
- name: oracle
uri: "10.20.30.40:2484"
protocol: oracle
tls:
mode: verify-ca
ca_cert_file: /var/lib/teleport/oracle-server-certificate.crt
Configure the Teleport Database Service to start automatically when the host boots up by creating a systemd service for it. The instructions depend on how you installed the Teleport Database Service.
- Package Manager
- TAR Archive
On the host where you will run the Teleport Database Service, enable and start Teleport:
sudo systemctl enable teleportsudo systemctl start teleport
On the host where you will run the Teleport Database Service, create a systemd service configuration for Teleport, enable the Teleport service, and start Teleport:
sudo teleport install systemd -o /etc/systemd/system/teleport.servicesudo systemctl enable teleportsudo systemctl start teleport
You can check the status of the Teleport Database Service with systemctl status teleport
and view its logs with journalctl -fu teleport
.
Create a secret containing the database CA certificate in the same namespace as Teleport using the following command:
kubectl create secret generic db-ca --from-file=ca.pem=/path/to/oracle-server-certificate.crt
Create a file called values.yaml
with the following content. Update
JOIN_TOKEN to the join token you created earlier using the tctl tokens add
command:
roles: db
proxyAddr: example.teleport.sh:443
enterprise: true
authToken: "JOIN_TOKEN"
databases:
- name: oracle
uri: "10.20.30.40:2484"
protocol: oracle
static_labels:
env: dev
tls:
mode: verify-ca
ca_cert_file: /etc/teleport-tls-db/db-ca/ca.pem
extraVolumes:
- name: db-ca
secret:
secretName: db-ca
extraVolumeMounts:
- name: db-ca
mountPath: /etc/teleport-tls-db/db-ca
readOnly: true
Teleport provides Helm charts for installing the Teleport Database Service in Kubernetes Clusters.
Set up the Teleport Helm repository.
Allow Helm to install charts that are hosted in the Teleport Helm repository:
helm repo add teleport https://charts.releases.teleport.dev
Update the cache of charts from the remote repository so you can upgrade to all available releases:
helm repo update
Install the chart:
helm install teleport-kube-agent teleport/teleport-kube-agent \ --create-namespace \ --namespace teleport-agent \ --version 17.0.0-dev \ -f values.yaml
Make sure that the Teleport Agent pod is running. You should see one
teleport-kube-agent
pod with a single ready container:
kubectl -n teleport-agent get podsNAME READY STATUS RESTARTS AGEteleport-kube-agent-0 1/1 Running 0 32s
Step 4/6. (Optional) Configure Teleport to pull audit logs from Oracle Audit Trail
Teleport can pull audit logs from Oracle Audit Trail. In order to enable this feature, you will need to configure Oracle Audit Trail and create a dedicated Teleport user that will be used to fetch audit events from Oracle Audit Trail.
Create an internal Oracle teleport
user that will fetch
audit events from Oracle Audit Trail:
CREATE USER teleport IDENTIFIED EXTERNALLY AS 'CN=teleport';
GRANT CREATE SESSION TO teleport;
GRANT SELECT ON dba_audit_trail TO teleport;
GRANT SELECT ON V_$SESSION TO teleport;
Enable the table in Oracle Audit Trail:
ALTER system SET audit_trail=db,extended scope=spfile;
Restart your Oracle instance to propagate audit trail changes.
Enable Oracle auditing for the alice
user:
AUDIT ALL STATEMENTS by alice BY access;
You must enable auditing for each Teleport user that will be used to connect to Oracle. Additionally you can create a different audit policy for each user.
Configure the Teleport Database Service to pull audit logs from Oracle Audit Trail:
db_service:
enabled: "yes"
databases:
- name: oracle
protocol: "oracle"
uri: "10.20.30.40:2484"
oracle:
audit_user: "teleport"
tls:
mode: verify-ca
ca_cert_file: /var/lib/teleport/oracle-server-certificate.crt
Teleport doesn't clean up audit trail events from Oracle Audit Trail. Make sure to configure an Oracle Audit Trail cleanup policy to avoid running out of disk space.
Step 5/6. Create a Teleport user
To modify an existing user to provide access to the Database Service, see Database Access Controls
- Teleport Community Edition
- Teleport Enterprise/Enterprise Cloud
Create a local Teleport user with the built-in access
role:
tctl users add \ --roles=access \ --db-users="*" \ --db-names="*" \ alice
Create a local Teleport user with the built-in access
and requester
roles:
tctl users add \ --roles=access,requester \ --db-users="*" \ --db-names="*" \ alice
Flag | Description |
---|---|
--roles | List of roles to assign to the user. The builtin access role allows them to connect to any database server registered with Teleport. |
--db-users | List of database usernames the user will be allowed to use when connecting to the databases. A wildcard allows any user. |
--db-names | List of logical databases (aka schemas) the user will be allowed to connect to within a database server. A wildcard allows any database. |
Database names are only enforced for PostgreSQL, MongoDB, and Cloud Spanner databases.
For more detailed information about database access controls and how to restrict access see RBAC documentation.
Step 6/6. Connect
Once the Database Service has joined the cluster, log in to see the available databases:
tsh login --proxy=example.teleport.sh --user=alicetsh db lsName Description Allowed Users Labels Connect
------ -------------- ------------- ------- -------
oracle [*] env=dev
Connect to the "oracle" database. Pass the correct service name as the --db-name
parameter.
You can check the service names by inspecting the database configuration on the Oracle Exadata VM.
> lsnrctl services | grep paasService "spark_PDB1.paas.oracle.com" has 1 instance(s).
tsh db connect --db-user alice --db-name spark_PDB1.paas.oracle.com oracleSQLcl: Release 24.2 Production on Fri Aug 09 15:29:41 2024
Copyright (c) 1982, 2024, Oracle. All rights reserved.
Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.24.0.0.0
SQL> select user from dual;
USER
________
ALICE
SQL>
To log out of the database and remove credentials:
Remove credentials for a particular database instance.
tsh db logout oracleRemove credentials for all database instances.
tsh db logout
Next steps
- Learn how to restrict access to certain users and databases.
- View the High Availability (HA) guide.
- Take a look at the YAML configuration reference.
- See the full CLI reference.
Read the documentation about: