Spin up Hosts Integrated with OPA
Create a .yaml
file named docker-compose.yaml
that runs OPA and the containers that represent the backend and frontend hosts.
Create the docker-compose.yaml
file, and copy the following YAML into it.
docker-compose.yaml
version: '2'
services:
opa:
image: openpolicyagent/opa:latest
ports:
- 8181:8181
# WARNING: OPA is NOT running with an authorization policy configured. This
# means that clients can read and write policies in OPA. If you are
# deploying OPA in an insecure environment, be sure to configure
# authentication and authorization on the daemon. See the Security page for
# details: https://www.openpolicyagent.org/docs/security.html.
environment:
- OPA_LOG_TIMESTAMP_FORMAT="2006-01-02T15:04:05.999999999Z07:00"
command:
- "run"
- "--server"
- "--config-file=/opa-conf.yaml"
volumes:
- ./opa-conf.yaml:/opa-conf.yaml
frontend:
image: openpolicyagent/demo-pam
ports:
- "2222:22"
volumes:
- ./frontend_host_id.json:/etc/host_identity.json
- ./sshd:/etc/pam.d/sshd
backend:
image: openpolicyagent/demo-pam
ports:
- "2223:22"
volumes:
- ./backend_host_id.json:/etc/host_identity.json
- ./sshd:/etc/pam.d/sshd
The docker-compose.yaml
file relies on a configuration file for OPA, so you must create a configuration file named opa-config.yaml
.
Create the opa-config.yaml
file, and copy the following YAML into it.
Specify the SYSTEMID
and the TOKEN
, and replace the URL path.
- The
SYSTEMID
is the numeric ID for the Custom System you created in Styra DAS. - For the
TOKEN
, you can generate an API token by referring to the Create an API Token page.
opa-conf.yaml
discovery:
name: discovery
prefix: /systems/SYSTEMID
labels:
policy-type: custom/rules
system-id: SYSTEMID
system-type: custom
services:
- credentials:
bearer:
token: TOKEN
name: styra
url: https://<das-id>.styra.com/v1
To control the policy-paths the PAM module uses to interact with OPA, the docker-compose.yaml
file overwrites the pam.d/sshd
file in the demo-pam
containers.
Create a file named sshd
.
There is no file extension for sshd
.
Copy the following SSHD configuration and paste it into the sshd
file.
SSHD Configuration
# PAM configuration for the Secure Shell service
# Enable the Authz PAM module
# At image build time, the value of HOST_UUID is replaced with the role of the image (for example, webapp)
auth required /lib/security/pam_authz.so url=http://opa:8181 authz_endpoint=/v1/data/rules/authz display_endpoint=/v1/data/rules/display pull_endpoint=/v1/data/rules/pull log_level=debug
# SELinux needs to be the first session rule. This ensures that any
# lingering context has been cleared. Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
# Set the loginuid process attribute.
session required pam_loginuid.so
# Create a new session keyring.
session optional pam_keyinit.so force revoke
# Standard Un*x session setup and teardown.
@include common-session
# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
# Print the status of the user's mailbox upon successful login.
session optional pam_mail.so standard noenv # [1]
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session required pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context. Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
# Standard Un*x password updating.
@include common-password
Each host can have metadata associated with it by creating JSON files in the file system. The content of the file provides context that the PAM module provides as input when executing queries against OPA.
In this tutorial, you can mount the metadata files frontend_host_id.json
and backend_host_id.json
into Styra's two different hosts, as follows.
echo '{"host_type": "frontend", "host_id": "1234"}' > frontend_host_id.json
echo '{"host_type": "backend", "host_id": "7890"}' > backend_host_id.json
In real-world scenarios, these files could contain arbitrary information that Styra wants to expose to the policy.
Run docker-compose
to pull and run the containers.
docker-compose up