Skip to content

Commit

Permalink
chore: docs linting changes (#505)
Browse files Browse the repository at this point in the history
## Description
Small changes for meeting npm linting rules in the uds-docs repo. Mostly
spacing and naming of code blocks.

## Type of change

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Other (security config, docs update, etc)

## Checklist before merging

- [x] Test, docs, adr added or updated as needed
- [x] [Contributor Guide
Steps](https://github.com/defenseunicorns/uds-template-capability/blob/main/CONTRIBUTING.md)(https://github.com/defenseunicorns/uds-template-capability/blob/main/CONTRIBUTING.md#submitting-a-pull-request)
followed
  • Loading branch information
UnicornChance committed Jun 24, 2024
1 parent 4aa6e33 commit 0fe2015
Show file tree
Hide file tree
Showing 5 changed files with 17 additions and 9 deletions.
6 changes: 4 additions & 2 deletions docs/configuration/uds-configure-policy-exemptions.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,9 +6,10 @@ weight: 3

By default policy exemptions ([UDSExemptions](https://github.com/defenseunicorns/uds-core/blob/uds-docs/src/pepr/operator/crd/generated/exemption-v1alpha1.ts)) are only allowed in a single namespace -- `uds-policy-exemptions`. We recognize this is not a conventional pattern in K8s, but believe it is ideal for UDS for the following reasons:

- highlights the fact that an exemption can reduce the overall security posture of the cluster
- highlights the fact that an exemption can reduce the overall security posture of the cluster
- makes maintaining RBAC for controlling exemptions more straightforward
- reduces the risk that an unintentional mis-configuration of RBAC allows a cluster exemption that would otherwise be denied

## Allow All Namespaces

If you believe that the default scoping is not the right approach for your cluster, you can configure UDS-CORE at deploy time to allow exemption CRs in all namespaces.
Expand All @@ -18,6 +19,7 @@ If you believe that the default scoping is not the right approach for your clust
or via a uds bundle config:

uds-config.yaml

```yaml
options:
# options here
Expand All @@ -28,4 +30,4 @@ shared:
variables:
# package specific variables here

```
```
7 changes: 4 additions & 3 deletions docs/configuration/uds-monitoring-metrics.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ type: docs
weight: 1
---

UDS Core leverages Pepr to handle setup of Prometheus scraping metrics endpoints, with the particular configuration necessary to work in a STRICT mTLS (Istio) environment. We handle this with both mutations of existing service monitors and generation of service monitors via the `Package` CR.
UDS Core leverages Pepr to handle setup of Prometheus scraping metrics endpoints, with the particular configuration necessary to work in a STRICT mTLS (Istio) environment. We handle this with both mutations of existing service monitors and generation of service monitors via the `Package` CR.

## Mutations

Expand Down Expand Up @@ -33,11 +33,11 @@ spec:
path: "/mymetrics" # Add if metrics are exposed on a different path than "/metrics"
```
This config is used to generate service monitors and corresponding network policies to setup scraping for your applications. The `ServiceMonitor`s will go through the mutation process to add `tlsConfig` and `scheme` to work in an istio environment.
This config is used to generate service monitors and corresponding network policies to setup scraping for your applications. The `ServiceMonitor`s will go through the mutation process to add `tlsConfig` and `scheme` to work in an istio environment.

This spec intentionally does not support all options available with a `ServiceMonitor`. While we may add additional fields in the future, we do not want to simply rebuild the `ServiceMonitor` spec since mutations are already available to handle Istio specifics. The current subset of spec options is based on the bare minimum necessary to craft resources.

NOTE: While this is a rather verbose spec, each of the above fields are strictly required to craft the necessary service monitor and network policy resources.
NOTE: While this is a rather verbose spec, each of the above fields are strictly required to craft the necessary service monitor and network policy resources.

## Notes on Alternative Approaches

Expand All @@ -46,6 +46,7 @@ In coming up with this feature a few alternative approaches were considered but
### Generation based on service lookup

An alternative spec option would use the service name instead of selectors/port name. The service name could then be used to lookup the corresponding service and get the necessary selectors/port name (based on numerical port). There are however 2 issues with this route:

1. There is a timing issue if the `Package` CR is applied to the cluster before the app chart itself (which is the norm with our UDS Packages). The service would not exist at the time the `Package` is reconciled. We could lean into eventual consistency here, if we implemented a retry mechanism for the `Package`, which would mitigate this issue.
2. We would need an "alert" mechanism (watch) to notify us when the service(s) are updated, to roll the corresponding updates to network policies and service monitors. While this is doable it feels like unnecessary complexity compared to other options.

Expand Down
7 changes: 6 additions & 1 deletion docs/configuration/uds-user-groups.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,9 @@ weight: 4
UDS Core deploys Keycloak which has some preconfigured groups that applications inherit from SSO and IDP configurations.

## Applications

### Grafana

Grafana [maps the groups](https://github.com/defenseunicorns/uds-core/blob/49cb11a058a9209cee7019fa552b8c0b2ef73368/src/grafana/values/values.yaml#L37) from Keycloak to it's internal `Admin` and `Viewer` groups.

| Keycloak Group | Mapped Grafana Group |
Expand All @@ -18,6 +20,7 @@ Grafana [maps the groups](https://github.com/defenseunicorns/uds-core/blob/49cb1
If a user doesn't belong to either of these Keycloak groups the user will be unauthorized when accessing Grafana.

### Neuvector

Neuvector [maps the groups](https://github.com/defenseunicorns/uds-core/blob/main/src/neuvector/chart/templates/uds-package.yaml#L31-L35) from Keycloak to it's internal `admin` and `reader` groups.

| Keycloak Group | Mapped Neuvector Group |
Expand All @@ -26,6 +29,7 @@ Neuvector [maps the groups](https://github.com/defenseunicorns/uds-core/blob/mai
| `Auditor` | `reader` |

## Keycloak

{{% alert-note %}}
All groups are under the Uds Core parent group. Frequently a group will be referred to as Uds Core/Admin or Uds Core/Auditor. In the Keycloak UI this requires an additional click to get down to the sub groups.
{{% /alert-note %}}
Expand All @@ -37,8 +41,9 @@ UDS Core ships with a [templated](https://github.com/defenseunicorns/uds-identit
Alternatively, the `realmInitEnv` can be configured via bundle overrides like in the [k3d-standard-bundle](https://github.com/defenseunicorns/uds-core/blob/main/bundles/k3d-standard/uds-bundle.yaml#L96).

Configuring your own IDP can be achieved via:

* Custom uds-identity-config with a templated realm.json

* Keycloak Admin UI and click ops

* Custom [realm.json](https://github.com/defenseunicorns/uds-identity-config/blob/main/src/realm.json#L1712-L1813) for direct import in Keycloak
* Custom [realm.json](https://github.com/defenseunicorns/uds-identity-config/blob/main/src/realm.json#L1712-L1813) for direct import in Keycloak
2 changes: 1 addition & 1 deletion docs/deployment/distribution-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,4 +16,4 @@ UDS Core is a versatile software baseline designed to operate effectively across
| --------------- | ---------------------- | --------------------------------------------------------------------------------------------------------- |
| K3d, Amazon EKS | Tested | Supported Kubernetes distributions undergoing testing in CI environments. |
| RKE2 | Tested | Supported Kubernetes distribution tested in production environments other than CI. |
| Other | Untested/Unknown state | Compatible Kubernetes distributions that are not explicitly tested, documented, or supported by UDS Core. |
| Other | Untested/Unknown state | Compatible Kubernetes distributions that are not explicitly tested, documented, or supported by UDS Core. |
4 changes: 2 additions & 2 deletions docs/development/uds-development-maintenance.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,8 @@ type: docs
weight: 1
---

# UDS Bundle [name]
## UDS Bundle [name]

## How to upgrade this bundle
### How to upgrade this bundle

[Description and steps for upgrading this UDS bundle. Include any historic problems to watch out for]

0 comments on commit 0fe2015

Please sign in to comment.